sourceip read only cloudfront aws amazon-s3 amazon-web-services policy bucket

amazon-s3 - read - s3 policy aws sourceip



¿Cómo puedo hacer público un grupo de S3(la política de ejemplo de Amazon no funciona)? (6)

Amazon proporciona un ejemplo para otorgar permiso a un usuario anónimo de la siguiente manera (consulte Casos de ejemplo para políticas de Amazon S3 Bucket ):

{ "Version": "2008-10-17", "Statement": [ { "Sid": "AddPerm", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::bucket/*" } ] }

Dentro de mi política he cambiado "bucket" en "arn: aws: s3 ::: bucket /" a "my-bucket".

Sin embargo, una vez que trato de acceder a una imagen dentro de una carpeta de ese grupo, obtengo el siguiente error de acceso denegado :

Este archivo XML no parece tener ninguna información de estilo asociada. La estructura del documento se muestra a continuación.

(Si cambio explícitamente las propiedades de esa imagen a públicas, luego recargo su url, la imagen se carga perfectamente)

¿Qué estoy haciendo mal?

Actualización # 1 : Aparentemente tiene algo que ver con un sitio de terceros al que he dado acceso. Aunque tiene todos los permisos como usuario principal (yo), y sus objetos están en la misma carpeta, con los mismos permisos exactos, todavía no me permite hacerlos visibles públicamente. No tengo idea de por qué.

Actualización # 2 : las políticas de cubetas no se aplican a los objetos "propiedad" de otros, incluso aunque estén dentro de su cubeta, vea mi respuesta para obtener más detalles.


Actualizar

Según el comentario de GoodGets, el problema real ha sido que las políticas del grupo no se aplican a los objetos "de propiedad" de otra persona, incluso aunque estén en su grupo , consulte la respuesta de GoodGets para más detalles (+1).

¿Es esta una nueva configuración de depósito / objeto o está intentando agregar una política de depósito a una configuración preexistente?

En este último caso, es posible que haya tropezado con una trampa relacionada debido a la interacción entre los tres mecanismos de control de acceso S3 disponibles, que pueden ser bastante confusos. Esto se aborda, por ejemplo, en el uso de ACL y políticas de cubeta juntas :

Cuando tiene las ACL y las políticas de depósito asignadas a los depósitos, Amazon S3 evalúa las actuales ACL de Amazon S3, así como la política de depósito al determinar los permisos de acceso de una cuenta a un recurso de Amazon S3. Si una cuenta tiene acceso a los recursos que especifica una política o ACL, pueden acceder al recurso solicitado.

Si bien esto suena bastante fácil, pueden surgir interferencias no intencionales a partir de los valores predeterminados diferentes entre las políticas de ACL y:

Con las ACL de Amazon S3 existentes, una concesión siempre proporciona acceso a un grupo u objeto. Cuando se usan políticas, un rechazo siempre anula una concesión . [énfasis mío]

Esto explica por qué agregar una subvención de ACL siempre garantiza el acceso, sin embargo, esto no se aplica a la adición de una subvención de política, porque una denegación de política explícita proporcionada en otra parte de su configuración aún se aplicará, como se ilustra más adelante en, por ejemplo, IAM y Bucket Policies Together and Evaluation La logica

Por consiguiente, recomiendo comenzar con una configuración nueva de cubo / objeto para probar la configuración deseada antes de aplicarla en un escenario de producción (lo que podría interferir, por supuesto, pero identificar / depurar la diferencia será más fácil en el caso).

¡Buena suerte!


El problema está en tu acción , debería estar en formato de matriz .

Prueba esto:

{ "Version":"2012-10-17", "Statement":[ { "Sid":"AddPerm", "Effect":"Allow", "Principal": "*", "Action":["s3:GetObject"], "Resource":["arn:aws:s3:::examplebucket/*"] } ] }

Pase su nombre Bucket en ''Recurso''


La siguiente política hará público todo el cubo:

{ "Version":"2012-10-17", "Statement":[ { "Sid":"AddPerm", "Effect":"Allow", "Principal": "*", "Action":["s3:GetObject"], "Resource":["arn:aws:s3:::examplebucket/*"] } ] }

Si desea que una carpeta específica bajo ese grupo sea pública utilizando las políticas del Grupo, debe hacer que esa carpeta / prefijo explícitamente sea pública y luego aplicar la política del grupo de la siguiente manera:

{ "Version":"2012-10-17", "Statement":[ { "Sid":"AddPerm", "Effect":"Allow", "Principal": "*", "Action":["s3:GetObject"], "Resource":["arn:aws:s3:::examplebucket/images/*"] } ] }

La política anterior permitirá la lectura pública de todos los objetos en las imágenes, pero no podrá acceder a otros objetos dentro del cubo.


Las políticas de cubo no aplican archivos con otros propietarios. Entonces, aunque he dado acceso de escritura a un tercero, la propiedad sigue siendo de ellos, y mi política de depósito no se aplicará a esos objetos.


Perdí horas en esto, la causa raíz era estúpida, y las soluciones mencionadas aquí no ayudaron (las probé todas), y los documentos de permisos de AWS s3 no enfatizaron este punto.

Si tiene activada la opción de pago de Requester Pays , no puede habilitar el acceso anónimo (ya sea por política de depósito o por ACL ''Todos''). Seguro que puede escribir las políticas y la ACL y aplicarlas, e incluso usar la consola para establecer explícitamente un archivo como público, pero una URL no firmada obtendrá un acceso 403 denegado el 100% del tiempo en ese archivo, hasta que deseleccione el requester pays configuración en la consola para todo el grupo (ficha de propiedades cuando se selecciona el grupo). O, supongo, a través de alguna llamada REST API.

Unquecked Requester Pays y ahora el acceso anónimo está funcionando, con restricciones de referencia, etc. Para ser justos, la consola de AWS nos dice:

Mientras Requester Pays está habilitado, el acceso anónimo a este grupo está deshabilitado.