I'm adding an answer with the same direction as the accepted answer but with small (important) differences and adding more details.
Consider the configuration below:
{
"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>/*"]
}
]
}
The policy grants programmatic write-delete access and is separated into two parts:
The ListBucket
action provides permissions on the bucket level and the other PutObject/DeleteObject
actions require permissions on the objects inside the bucket.
The first Resource element specifies arn:aws:s3:::<Bucket-Name>
for the ListBucket
action so that applications can list all objects in the bucket.
The second Resource element specifies arn:aws:s3:::<Bucket-Name>/*
for the PutObject
, and DeletObject
actions so that applications can write or delete any objects in the bucket.
The separation into two different 'arns' is important from security reasons in order to specify bucket-level and object-level fine grained permissions.
Notice that if I would have specified just GetObject
in the 2nd block what would happen is that in cases of programmatic access I would receive an error like:
Upload failed: <file-name> to <bucket-name>:<path-in-bucket> An error occurred (AccessDenied) when calling the PutObject operation: Access Denied
.
aws
for one user and used it inside a cronjob-called bash script from another user, meaning the access key and access token were wrong/unset. My solution was to directly put the credentials (AWS_ACCESS_KEY_ID
andAWS_SECRET_ACCESS_KEY
) into my bash script file as described here. – Uwe Keim