Archivos proxy de AWS S3 con nginx

Parece que la tarea de implementar la interfaz para AWS en nginx suena como un caso típico de StackOverflow: después de todo, ¿no puede haber problemas con la representación de archivos desde S3? De hecho, resultó que una solución preparada no es tan fácil de encontrar, y este artículo debería corregir esta situación.

¿Por qué necesitarías esto?

1. Controle el acceso a los archivos usando nginx: relevante para el concepto de IaC (infraestructura como código). Todos los cambios relacionados con el acceso se realizarán solo en las configuraciones que están en el proyecto.
2. Si entrega archivos a través de su nginx, puede guardarlos en caché y guardar las solicitudes en S3.
3. Tal proxy ayudará a ignorar el tipo de almacenamiento de archivos para diferentes instalaciones de aplicaciones (después de todo, hay otras soluciones además de S3).

Formulamos el marco

• El depósito de origen debe ser privado : no puede permitir que usuarios anónimos descarguen archivos directamente desde S3. Si en su caso esta restricción no funciona, simplemente use proxy_pass y ya no podrá leer.
• El ajuste por AWS debe ser de una sola vez "sintonizado y olvidado" para simplificar la operación.

Estamos buscando una solución en la frente.

Si su depósito original es público, entonces no hay amenazas que lo amenacen, las solicitudes de proxy para S3 y todo funcionará. Si es privado, tendrá que autenticarse con S3 de alguna manera. ¿Qué nos ofrecen los colegas de Internet?

1. Hay ejemplos de implementación del protocolo de autenticación usando nginx. La solución es buena, pero desafortunadamente, está diseñada para un protocolo de autenticación obsoleto ( Signature v2 ), que no funciona en algunos centros de datos de Amazon . Si intenta utilizar esta solución, por ejemplo, en Frankfurt, recibirá el error "El mecanismo de autorización que ha proporcionado no es compatible. Utilice AWS4-HMAC-SHA256 " . Una versión más reciente del protocolo ( Signature v4 ) es mucho más difícil de implementar, pero no hay soluciones listas para usar con nginx.
2. Hay un módulo de terceros para nginx: ngx_aws_auth . A juzgar por la fuente, es compatible con Signature v4. Sin embargo, el proyecto parece abandonado: durante más de un año no ha habido cambios en la base del código, y también hay un problema de compatibilidad con otros módulos a los que el desarrollador no responde. Además, agregar módulos adicionales a nginx es a menudo un paso doloroso en sí mismo.
3. Puede usar un proxy s3 separado, del cual se ha escrito bastante. Personalmente, me gustó la solución Go: aws-s3-proxy : tiene una imagen lista y bastante popular en DockerHub. Pero en este caso, la aplicación adquirirá otro componente con sus posibles problemas.

Aplicar la política de AWS Bucket

AWS, por regla general, asusta a los nuevos usuarios con su complejidad y volumen de documentación. Pero si miras, entiendes que está diseñado de manera muy lógica y flexible. Amazon también encontró una solución para nuestra tarea: S3 Bucket Policy . Este mecanismo le permite crear reglas de autorización flexibles para el depósito en función de diferentes parámetros del cliente o solicitud.


Interfaz del generador de políticas: generador de políticas de AWS

Aquí hay algunas opciones interesantes a las que puede unirse:

• IP ( aws:SourceIp ),
• Referer header ( aws:Referer ),
• aws:UserAgent agente de usuario ( aws:UserAgent ),
• El resto se describe en la documentación .

El enlace de IP es una buena opción solo si la aplicación tiene un cierto lugar de residencia, y en nuestro tiempo es raro. En consecuencia, debe apegarse a otra cosa. Como solución, propongo generar un Usuario-Agente o Referente secreto y dar archivos solo a aquellos usuarios que conocen el encabezado secreto. Así es como se ve una política similar:

 { "Version": "2012-10-17", "Id": "http custom auth secret", "Statement": [ { "Sid": "Allow requests with my secret.", "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::example-bucket-for-habr/*", "Condition": { "StringLike": { "aws:UserAgent": [ "xxxyyyzzz" ] } } } ] } 

Una pequeña explicación:

• "Version": "2012-10-17" es la cocina interna de AWS que no necesita editar;
• Principal : quién se ve afectado por esta regla. Puede especificar que solo funciona para una cuenta de AWS específica, pero en nuestro caso cuesta "*" , esto significa que la regla funciona para todos, incluidos los usuarios anónimos;
• Resource : depósito y plantilla ARN (nombre de recurso de Amazon) para archivos dentro del depósito. En nuestro caso, la política se aplica a todos los archivos que se encuentran en el example-bucket-for-habr ;
• Condition : estas son las condiciones que deben converger para que la política funcione. En nuestro caso, estamos comparando el encabezado User-Agent predefinido con la línea xxxyyyzzz .

Y así es como se ve el trabajo de esta regla desde el punto de vista de un usuario anónimo:

 $ curl -I https://s3.eu-central-1.amazonaws.com/example-bucket-for-habr/hello.txt HTTP/1.1 403 Forbidden $ curl -I https://s3.eu-central-1.amazonaws.com/example-bucket-for-habr/hello.txt -H 'User-Agent: xxxyyyzzz' HTTP/1.1 200 OK 

Queda por configurar nginx para proxy:

  location /s3-media/ { limit_except GET { deny all; } set $aws_bucket "example-bucket-for-habr"; set $aws_endpoint "s3.eu-central-1.amazonaws.com:443"; set $aws_custom_secret "xxxyyyzzz"; proxy_set_header User-Agent $aws_custom_secret; rewrite ^/s3-media/(.*)$ /$aws_bucket/$1 break; proxy_buffering off; proxy_pass https://$aws_endpoint; } 

Conclusión

En total, una vez que escribimos una política simple para bucket, tuvimos la oportunidad de usar archivos proxy con seguridad usando nginx. Sin embargo, no estamos atados por IP y no dependemos de software adicional.

PS

Lea también en nuestro blog:

• " Awless: una poderosa utilidad CLI alternativa para trabajar con los servicios de AWS ";
• " Rook es un almacén de datos " autoservicio " para Kubernetes ";
• " Teoría y práctica de copias de seguridad con Borg ".