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-eliminación y se divide en dos partes:
la ListBucket
acción proporciona permisos en el nivel de depósito y las otras PutObject/DeleteObject
acciones requieren permisos en los objetos dentro del depósito.
El primer elemento Resource especifica arn:aws:s3:::<Bucket-Name>
la ListBucket
acción para que las aplicaciones puedan enumerar todos los objetos en el depósito.
El segundo elemento Resource especifica arn:aws:s3:::<Bucket-Name>/*
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 razones de seguridad para especificar permisos de grano fino a nivel de cubo y de objeto.
Tenga en cuenta que si hubiera especificado solo GetObject
en el segundo bloque, lo que sucedería es que, en 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
.
aws
para un usuario y lo usé dentro de un script bash llamado cronjob de otro usuario, lo que significa que la clave de acceso y el token de acceso estaban incorrectos / desarmados. Mi solución fue poner directamente las credenciales (AWS_ACCESS_KEY_ID
yAWS_SECRET_ACCESS_KEY
) en mi archivo de script bash como se describe aquí .