The way we create buckets in our org and ensure sane ACLs around it is by providing an automated tool (that internally uses Terraform) to provision an S3 bucket. So say when a user requests for a new bucket, named
testBucket we create a bucket named
testBucket and also create an IAM user by the name
testBucket-user. The automation ensures that the
testBucket-user's policies are such that the only allowed actions to this user are :
"s3:ListBucket", "s3:PutObject", "s3:GetObject"
and the only allowed resource on which the above actions are allowed is the
Similarly, the automation also ensures that the automation puts bucket policies to ensure that the only actions allowed on it are the above 3 actions and only by the user
However, on demand (& if business justified) we do make changes to the created bucket policies as and when needed. So recently there was one such requirement, where a certain bucket needed to have a folder in it that was meant to hold all publicly intended images.
Now there were 2 options we had in order to provision the above requirement:
- Modify the bucket policy to allow
principal:*for the folder in the bucket thus allowing all objects in that folder in the bucket to be by default public.
- To modify and give PutObjectACL permissions to the IAM user that has access to that bucket and let the dev manage which objects in the folder can be or can not be public.
As the security team we were more convinced of the first option just because it looked more logical. The problem with the first option however was the fact that now any object (publicly intended or even otherwise) in this folder would be by default public.
I wonder what does the community think here around it? AWS/IAM experts, what would be your choice of the two options above and why ?