Configuré una distribución de CloudFront y una función de Lambda@Edge como se describe en este artículo:
Ahora quiero limitar el depósito de S3 para que sea privado y solo permitir el acceso de distribución de CloudFront al depósito. Agregué una Identidad de acceso de origen a la configuración de S3 Origin y actualicé la política del depósito para permitir que este OAI GetObject acceda al depósito. Eliminé la declaración de la política del depósito que la hacía legible públicamente y cambié la ACL para que sea privada. Si no incluyo ningún parámetro de cadena de consulta en la solicitud a CloudFront, la imagen se devuelve como se esperaba y no se puede acceder directamente al enlace de S3.
Sin embargo, la solución se basa en pasar parámetros de consulta para cambiar el tamaño de las imágenes sobre la marcha (a través de 2 funciones de Lambda@Edge) y después de hacer que el depósito sea privado, recibo una respuesta de acceso denegado 403 de CloudFront.
Intenté deshabilitar el reenvío de cadenas de consulta que no tuvo ningún efecto. También intenté solo actualizar la política del depósito para eliminar el acceso público de lectura y dejar la ACL como PublicRead y funcionó. Así que me hace pensar que algo está pasando con la ACL configurada como privada
Me preguntaba si tal vez S3 está devolviendo un 403 en lugar de un 404 cuando el cubo se hace privado. Pero entonces no entiendo por qué agregar el parámetro de cadena de consulta en la lista blanca produce un resultado diferente a la solicitud de la misma imagen sin cadena de consulta
Actualizar
Ejemplo de URL de trabajo: http://<my_distro>.cloudfront.net/images/house.jpeg
Ejemplo de URL rota: http://<my_distro>.cloudfront.net/images/house.jpeg?size=1200
Después de investigar, resulta que si un depósito es privado, S3 devolverá un 403 en lugar de un 404 si no existe un objeto en el depósito, lo que tiene sentido desde el punto de vista de la seguridad (evita la enumeración de objetos, etc.).
El código de solicitud del espectador en Lambda de la publicación del blog transformó la URL de la imagen cuando la cadena de consulta estaba presente. Si esta imagen no existe, la genera sobre la marcha. La función de respuesta de origen de la publicación del blog está verificando un estado de 404 para activar el cambio de tamaño de la imagen. Sin embargo, cuando el depósito se hace privado, la respuesta es 403, por lo que Lambda@Edge simplemente reenvía la respuesta. La solución es manejar el 403 o hacer público el depósito. me he ido con el primero
Lambda@Edge funciona con s3 a través de un usuario especial. Entonces, debe agregar reglas en su política de depósito s3, como esta:
{ "Version": "2008-10-17", "Id": "PolicyForCloudFrontPrivateContent", "Statement": [ { "Sid": "1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity XXXXX" }, "Action": [ "s3:GetObject" ], "Resource": "arn:aws:s3:::xxx/*" }, { "Sid": "2", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity XXXX" }, "Action": [ "s3:ListBucket" ], "Resource": "arn:aws:s3:::xxxx" } ] }