¿Por qué los usuarios de IAM de otra cuenta de AWS reciben errores de acceso denegado a pesar de que mi política de bucket concede total acceso a esa cuenta?
La política de mi bucket de Amazon Simple Storage Service (Amazon S3) concede total acceso a otra cuenta de AWS. Sin embargo, cuando los usuarios de AWS Identity and Access Management (IAM) de esa cuenta intentan acceder a mi bucket, aparece un error de acceso denegado.
Descripción breve
Si su política de bucket ya concede acceso a la otra cuenta, los usuarios con varias cuentas pueden recibir errores de acceso denegado por los siguientes motivos:
- La política de IAM del usuario no concede acceso al bucket.
- AWS Key Management Service (AWS KMS) ha cifrado el objeto y el usuario no tiene acceso a la clave de AWS KMS.
- Una instrucción de denegación en la política de bucket o en la política de IAM bloquea el acceso del usuario.
- La política de puntos de conexión de Amazon Virtual Private Cloud (Amazon VPC) bloquea el acceso al bucket.
- La política de control de servicios de AWS Organizations bloquea el acceso al bucket.
- El objeto no pertenece a la cuenta de AWS propietaria del bucket.
- Ha activado Pago por solicitante para el bucket.
- Ha aprobado una política de sesión que bloquea el acceso al bucket.
Solución
Nota: Si recibe errores al ejecutar los comandos de la Interfaz de la línea de comandos de AWS (AWS CLI), asegúrese de usar la versión más reciente.
La política de IAM del usuario no concede acceso al bucket
Para el acceso entre cuentas, asegúrese de conceder acceso al bucket tanto en la política de IAM de la cuenta A como en la política de bucket de la cuenta B.
Siga estos pasos para comprobar la política de IAM del usuario en la cuenta A:
1. Abra la consola de IAM.
2. Desde la consola, abra el usuario o rol de IAM que no puede acceder al bucket.
3. En la pestaña Permisos del usuario o rol de IAM, expanda cada política para ver su documento de política de JSON.
4. En los documentos de políticas de JSON, busque las políticas con el nombre del bucket. Después, confirme que esas políticas permiten las acciones de S3 correctas en el bucket.
5. Si el usuario o el rol de IAM no conceden acceso al bucket, agregue una política que conceda los permisos adecuados. Por ejemplo, la siguiente política de IAM concede acceso a un usuario para descargar objetos (s3:GetObject) desde DOC-EXAMPLE-BUCKET:
{ "Version": "2012-10-17", "Statement": [ { "Sid": "ExampleStmt", "Action": "s3:GetObject", "Effect": "Allow", "Resource": [ "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*" ] } ] }
AWS KMS ha cifrado el objeto y el usuario no tiene acceso a la clave de AWS KMS
Si tanto la política de IAM (cuenta A) como la política de bucket (cuenta B) permiten el acceso entre cuentas, compruebe el cifrado predeterminado del bucket con AWS KMS. También puede comprobar las propiedades del objeto para ver el cifrado de AWS KMS. Si una clave de AWS KMS ha cifrado el objeto, el usuario también debe gozar de permisos para usar la clave.
Para conceder a un usuario de IAM los permisos para descargar y subir archivos a un bucket cuando use una clave de KMS para el cifrado, siga estos pasos:
1. Edite la política de claves de KMS para añadir una instrucción similar a la siguiente:
Nota: Introduzca el nombre de recurso de Amazon (ARN) del usuario de IAM como la Entidad principal.
{ "Sid": "ExampleStmt", "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:user/Jane" }, "Resource": "*" }
2. Si la clave de KMS pertenece a la misma cuenta que la del usuario de IAM, no es necesario que modifique la política de claves. Si la clave de KMS pertenece a una cuenta diferente a la del usuario de IAM, también debe modificar los permisos del usuario de IAM. Agregue una instrucción de política de IAM similar a la siguiente:
Nota: Introduzca el ARN de la clave de KMS como el Recurso.
{ "Sid": "KMSAccess", "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Effect": "Allow", "Resource": "arn:aws:kms:example-region-1:123456789098:key/111aa2bb-333c-4d44-5555-a111bb2c33dd" }
Una instrucción de denegación en la política de bucket o en la política de IAM bloquea el acceso del usuario
Consulte la política de bucket y las políticas de IAM del usuario para ver si hay alguna instrucción que deniegue explícitamente el acceso del usuario al bucket.
Siga estos pasos para comprobar la política de bucket:
1. Abra la consola de Amazon S3.
2. En la lista de buckets, abra el bucket con la política de bucket que quiera comprobar.
3. Seleccione la pestaña Permisos.
4. Elija Política de bucket.
5. Busque instrucciones con "Effect": "Deny".
6. Modifique la política de bucket para editar o eliminar cualquier instrucción de "Effect": "Deny" que deniegue el acceso del usuario al bucket.
Siga estos pasos para comprobar las políticas de IAM del usuario:
1. Abra la consola de IAM.
2. Desde la consola, abra el usuario o rol de IAM que no puede acceder al bucket.
3. En la pestaña Permisos del usuario o rol de IAM, expanda cada política para ver los documentos de políticas de JSON.
4. En los documentos de políticas de JSON, busque políticas relacionadas con el bucket de S3 con instrucciones que contengan "Effect": "Deny".
5. Modifique las políticas de permisos de IAM del usuario para editar o eliminar las instrucciones de «Efecto»: "Deny" que denieguen de forma incorrecta el acceso del usuario al bucket.
La política de puntos de conexión de VPC bloquea el acceso al bucket
Si los usuarios acceden al bucket con una instancia de Amazon Elastic Compute Cloud (Amazon EC2) que se dirija mediante un punto de conexión de VPC, compruebe la política de puntos de conexión de VPC. Confirme que la política de puntos de conexión de VPC incluya los permisos adecuados para acceder al bucket de S3.
Por ejemplo, la siguiente política de puntos de conexión de VPC permite el acceso a DOC-EXAMPLE-BUCKET:
{ "Id": "Policy1234567890123", "Version": "2012-10-17", "Statement": [ { "Sid": "Stmt1234567890123", "Action": [ "s3:GetObject", "s3:PutObject" ], "Effect": "Allow", "Resource": [ "arn:aws:s3:::DOC-EXAMPLE-BUCKET", "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*" ], "Principal": "*" } ] }
Advertencia: El elemento «Entidad principal»: «*» permite que todos los que usen el punto de conexión de VPC tengan acceso al bucket. Asegúrese de restringir el alcance del valor Entidad principal según corresponda para su caso de uso.
La política de control de servicios de AWS Organizations bloquea el acceso al bucket
Si la cuenta del usuario ha activado AWS Organizations, compruebe las políticas de control de servicios para asegurarse de que se permite el acceso a Amazon S3. Por ejemplo, la siguiente política deniega explícitamente el acceso a Amazon S3 y produce un error de acceso denegado:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "s3:*", "Resource": "*" } ] }
Para obtener más información sobre las características de AWS Organizations, consulte Habilitar todas las características en la organización.
El objeto no pertenece a la cuenta de AWS propietaria del bucket
De forma predeterminada, un objeto de S3 pertenece a la cuenta de AWS que lo cargó. Esto es así incluso cuando el bucket es propiedad de otra cuenta. Los permisos del bucket no se aplican automáticamente a un objeto cuando el objeto es propiedad de otra cuenta.
Para resolver los errores de acceso denegado relacionados con la propiedad del objeto, pruebe las siguientes soluciones:
- Se recomienda desactivar las listas de control de acceso (ACL) de los buckets de Amazon S3. Para desactivar las ACL, aplique la configuración impuesta por el propietario del bucket para la propiedad de objetos de S3. Si aplica esta configuración, será el propietario de todos los objetos del bucket y tendrá control total sobre ellos.
- Para imponer la propiedad de los objetos nuevos sin desactivar las ACL, aplique la configuración preferida del propietario del bucket. Al aplicar esta configuración, se recomienda actualizar la política de bucket para exigir la ACL predefinida bucket-owner-full-control para todas las solicitudes PUT del bucket. El propietario del objeto puede conceder acceso al propietario del bucket con el comando put-object-acl:
$ aws s3api put-object-acl --bucket examplebucket --key keyname --acl bucket-owner-full-control
Nota: Para acceder al objeto, el propietario del objeto debe conceder acceso al propietario del bucket de forma explícita. Por lo tanto, use la cuenta del propietario del objeto para ejecutar estos comandos.
Ha activado Pago por solicitante para el bucket
Si ha activado Pago por solicitante para el bucket, los usuarios de otras cuentas deberán especificar el parámetro request-payer al enviar solicitudes al bucket. De lo contrario, los usuarios recibirán un error de acceso denegado.
Para resolverlo, realice las siguientes acciones:
- Para las solicitudes DELETE, GET, HEAD, POST y PUT, incluya x-amz-request-payer : requester en el encabezado.
- Para las URL firmadas, incluya x-amz-request-payer=requester en la solicitud.
- Para los comandos de la AWS CLI, incluya el parámetro**--request-payer**. Ejemplo:
$ aws s3 cp exampleobject.jpg s3://DOC-EXAMPLE-BUCKET/exampleobject.jpg --request-payer requester
Ha aprobado una política de sesión que bloquea el acceso al bucket
Una política de sesión es una política en línea que puede crear y aprobar rápidamente en la sesión durante la asunción del rol. Puede aprobar la política de sesión para ampliar el alcance de los permisos de la sesión de rol. Las políticas de sesión son políticas avanzadas que se aprueban como parámetro al crear una sesión temporal para un rol o un usuario federado de forma programática. Los permisos efectivos de la sesión son la intersección de las políticas basadas en identidades del rol y la política de sesión. Por lo tanto, asegúrese de que la política de sesión que ha aprobado no bloquee el acceso al bucket de S3.
Información relacionada
¿Cómo soluciono los errores de acceso denegado 403 de Amazon S3?
Contenido relevante
- OFICIAL DE AWSActualizada hace 2 años
- OFICIAL DE AWSActualizada hace 2 años