Ha otorgado permiso para ejecutar comandos en objetos dentro del depósito de S3, pero no ha otorgado permiso para realizar ninguna acción en el propio depósito.

Modificando ligeramente su política se vería así:

 { "Version": "version_id", "Statement": [ { "Sid": "some_id", "Effect": "Allow", "Action": [ "s3:*" ], "Resource": [ "arn:aws:s3:::bucketname", "arn:aws:s3:::bucketname/*" ] } ] }

Sin embargo, eso probablemente da más permiso del necesario. Seguir la mejor práctica de AWS IAM de otorgar privilegios mínimos se vería así:

 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::bucketname" ] }, { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::bucketname/*" ] } ] }

No pude acceder a S3 porque

• primero configuré el acceso clave en la instancia (era imposible adjuntar el rol después del lanzamiento)
• lo olvidé por unos meses
• rol adjunto a la instancia
• trató de acceder. La clave configurada tenía mayor prioridad que el rol y se denegó el acceso porque al usuario no se le otorgaron los permisos de S3 necesarios.

Solución: rm -rf .aws/credentials , luego aws usa el rol.

Debe especificar Resource para el depósito a través de "arn:aws:s3:::bucketname" o "arn:aws:3:::bucketname*" . Se prefiere este último ya que también permite manipulaciones en los objetos del cubo. ¡Observe que no hay barra!

Enumerar objetos es una operación en Bucket. Por lo tanto, se requiere la acción "s3:ListBucket" . Agregar un objeto al Cubo es una operación en el Objeto. Por lo tanto, se necesita la acción "s3:PutObject" . Ciertamente, es posible que desee agregar otras acciones según lo requiera.

 { "Version": "version_id", "Statement": [ { "Sid": "some_id", "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:PutObject" ], "Resource": [ "arn:aws:s3:::bucketname*" ] } ] }

Si desea copiar todos los objetos del depósito s3 con el comando "aws s3 cp s3://bucket-name/data/all-data/ . --recursive" como mencionó, aquí hay una política segura y mínima para hacerlo:

 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::bucket-name" ], "Condition": { "StringLike": { "s3:prefix": "data/all-data/*" } } }, { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::bucket-name/data/all-data/*" ] } ] }

La primera declaración de esta política permite listar objetos dentro del subdirectorio de un depósito específico. El recurso debe ser el arn del depósito de S3, y para limitar la lista a solo un subdirectorio en ese depósito, puede editar el valor "s3: prefijo".

La segunda declaración de esta política permite obtener objetos dentro del depósito en un subdirectorio específico. Esto significa que podrá copiar todo lo que esté dentro de la ruta "s3://bucket-name/data/all-data/". Tenga en cuenta que esto no le permite copiar desde rutas principales como "s3://bucket-name/data/".

Esta solución es específica para limitar el uso de los comandos de la CLI de AWS; si necesita limitar el acceso a S3 a través de la consola o la API de AWS, se necesitarán más políticas. Sugiero echar un vistazo aquí: https://aws.amazon.com/blogs/security/writing-iam-policies-grant-access-to-user-specific-folders-in-an-amazon-s3-bucket/ .

Se puede encontrar un problema similar a este here que me llevó a la solución que estoy dando. https://github.com/aws/aws-cli/issues/2408

¡Espero que esto ayude!

Recibí el mismo error al usar la política que se muestra a continuación, aunque tengo "s3:ListBucket" para la operación s3:ListObjects.

 { "Version": "2012-10-17", "Statement": [ { "Action": [ "s3:ListBucket", "s3:GetObject", "s3:GetObjectAcl" ], "Resource": [ "arn:aws:s3:::<bucketname>/*", "arn:aws:s3:::*-bucket/*" ], "Effect": "Allow" } ] }

Luego lo arreglé agregando una línea "arn:aws:s3:::bucketname"

 { "Version": "2012-10-17", "Statement": [ { "Action": [ "s3:ListBucket", "s3:GetObject", "s3:GetObjectAcl" ], "Resource": [ "arn:aws:s3:::<bucketname>", "arn:aws:s3:::<bucketname>/*", "arn:aws:s3:::*-bucket/*" ], "Effect": "Allow" } ] }

Me enfrenté con el mismo problema. Acabo de agregar la configuración de credenciales:

 aws_access_key_id = your_aws_access_key_id aws_secret_access_key = your_aws_secret_access_key

en "~/.aws/credentials" + reinicie el terminal para el perfil predeterminado.

En el caso de perfiles múltiples, es necesario agregar --profile arg:

 aws s3 sync ./localDir s3://bucketName --profile=${PROFILE_NAME}

donde NOMBRE_PERFIL :

 .bash_profile ( or .bashrc) -> export PROFILE_NAME="yourProfileName"

Puede encontrar más información sobre cómo configurar credenciales y perfiles múltiples aquí

Estaba pensando que el error se debe a la acción "s3 :ListObjects" , pero tuve que agregar la acción "s3:ListBucket" para resolver el problema "Acceso denegado para ListObjects para el depósito S3"

Me gusta más esto que cualquiera de las respuestas anteriores. Muestra cómo usar el formato YAML y le permite usar una variable para especificar el depósito.

 - PolicyName: "AllowIncomingBucket" PolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Action: "s3:*" Resource: - !Ref S3BucketArn - !Join ["/", [!Ref S3BucketArn, '*']]

Estoy agregando una respuesta con la misma dirección que la respuesta aceptada pero con pequeñas diferencias (importantes) y agregando más detalles.

Considere la siguiente configuración:

 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:ListBucket"], "Resource": ["arn:aws:s3:::<Bucket-Name>"] }, { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:DeleteObject" ], "Resource": ["arn:aws:s3:::<Bucket-Name>/*"] } ] }

La política otorga acceso programático de escritura y eliminación y se divide en dos partes:
La acción ListBucket proporciona permisos en el nivel del depósito y las otras acciones PutObject/DeleteObject requieren permisos en los objetos dentro del depósito.

El primer elemento Resource especifica arn:aws:s3:::<Bucket-Name> para la acción ListBucket para que las aplicaciones puedan enumerar todos los objetos en el depósito.

El segundo elemento Resource especifica arn:aws:s3:::<Bucket-Name>/* para las acciones PutObject y DeletObject para que las aplicaciones puedan escribir o eliminar cualquier objeto en el depósito.

La separación en dos 'arns' diferentes es importante por motivos de seguridad para especificar permisos detallados a nivel de depósito y de objeto.

Tenga en cuenta que si hubiera especificado solo GetObject en el segundo bloque, lo que sucedería es que, en los casos de acceso programático, recibiría un error como:

Upload failed: <file-name> to <bucket-name>:<path-in-bucket> An error occurred (AccessDenied) when calling the PutObject operation: Access Denied .

Para permitir permisos en el depósito s3, vaya a la pestaña de permisos en el depósito s3 y en la política del depósito cambie la acción a esto, lo que permitirá que se realicen todas las acciones:

 "Action":"*"

Tuve este problema, mi requisito quería permitir que el usuario escribiera en una ruta específica

 { "Sid": "raspiiotallowspecificBucket", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::<bucketname>/scripts", "arn:aws:s3:::<bucketname>/scripts/*" ] },

y el problema fue solucionado con este cambio

 { "Sid": "raspiiotallowspecificBucket", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::<bucketname>", "arn:aws:s3:::<bucketname>/*" ] },

Me encontré con problemas similares, para mí el problema era que tenía diferentes claves de AWS configuradas en mi bash_profile.

Respondí una pregunta similar aquí: https://stackoverflow.com/a/57317494/11871462

Si tiene claves de AWS en conflicto en su bash_profile, la CLI de AWS las utiliza de manera predeterminada.

Intenté lo siguiente:

 aws s3 ls s3.console.aws.amazon.com/s3/buckets/{bucket name}

Esto me dio el error:

 An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied

Usar este formulario funcionó:

 aws s3 ls {bucket name}

De acuerdo, para aquellos que han hecho todo lo anterior y aún tienen este problema, intente esto:

La política de depósito debería tener este aspecto:

 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowBucketSync", "Effect": "Allow", "Principal": "*", "Action": [ "s3:PutObject", "s3:GetObject", "s3:PutObjectAcl", "s3:DeleteObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::BUCKET_NAME", "arn:aws:s3:::BUCKET_NAME/*" ] } ] }

Luego guarde y asegúrese de que su Instancia o Lightsail esté conectado al perfil correcto en AWS Configure.

Primero: intente agregar --recursive al final, ¿algo de suerte? No está bien, prueba con el de abajo.

Segundo: Bien, ahora prueba esto en su lugar: --no-sign-request

por lo que debería verse así:

 sudo aws s3 sync s3://BUCKET_NAME /yourpath/path/folder --no-sign-request

De nada 😂

Tuve un problema similar al intentar sincronizar localmente un depósito s3 completo. Para mí, MFA (autenticación multifactor) se aplicó en mi cuenta, lo cual es necesario al realizar comandos a través de AWS CLI.

Entonces, la solución para mí fue: proporcionar credenciales de mfa usando un perfil ( documentación de mfa ) mientras usaba cualquier comando de AWS CLI.

Tuve el mismo problema. Tuve que proporcionar el recurso y la acción correctos, el recurso es el arn y la acción de su depósito en su permiso deseado. Además, asegúrese de tener su arn de usuario correcto. A continuación se muestra mi solución.

 { "Version": "2012-10-17", "Id": "Policy1546414123454", "Statement": [ { "Sid": "Stmt1546414471931", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789101:root" }, "Action": ["s3:ListBucket", "s3:ListBucketVersions"], "Resource": "arn:aws:s3:::bucket-name" } ] }

Aquí está la política que funcionó para mí.

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

Mi problema fue haber establecido

 env: AWS_ACCESS_KEY_ID: {{ secrets.AWS_ACCESS_KEY_ID }} AWS_SECRET_ACCESS_KEY: {{ secrets.AWS_SECRET_ACCESS_KEY }}

de nuevo, en aws-sync GitHub Action como variables de entorno. Venían de mi configuración de GitHub. Aunque en mi caso había asumido un rol en el paso anterior que me establecería algunas claves nuevas en esas mismas variables de entorno de nombre. Así que estaba sobrescribiendo las buenas claves supuestas con las malas claves básicas de GitHub.

Tenga cuidado con esto si está asumiendo roles.