Я добавляю ответ в том же направлении, что и принятый ответ, но с небольшими (важными) отличиями и добавляю больше деталей.
Рассмотрим конфигурацию ниже:
{
"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>/*"]
}
]
}
Политика предоставляет программные записи-удаления доступа и разделяется на две части: действие обеспечивает разрешения на уровне ведра и другие действия требуют разрешения на доступ к объектам внутри ведра.
ListBucket
PutObject/DeleteObject
Первый элемент Resource указывает arn:aws:s3:::<Bucket-Name>
дляListBucket
действие , так что приложения могут перечислить все объекты в ведре.
Второй элемент определяет ресурсы arn:aws:s3:::<Bucket-Name>/*
для PutObject
, иDeletObject
действий , так что приложения могут писать или удалять любые объекты в ведре.
Разделение на два разных «arns» важно из соображений безопасности, чтобы указать детализированные разрешения на уровне корзины и на уровне объекта.
Обратите внимание, что если бы я указал только GetObject
во втором блоке, то в случае программного доступа я бы получил сообщение об ошибке:
Upload failed: <file-name> to <bucket-name>:<path-in-bucket> An error occurred (AccessDenied) when calling the PutObject operation: Access Denied
,
aws
для одного пользователя и использовал его внутри bash-скрипта, называемого cronjob, от другого пользователя, то есть ключ доступа и токен доступа были неправильными / не были установлены. Мое решение заключалось в том, чтобы напрямую поместить учетные данные (AWS_ACCESS_KEY_ID
иAWS_SECRET_ACCESS_KEY
) в мой файл сценария bash, как описано здесь .