This is not really a question but an observation.
There’s a small error in the video when creating a bucket policy at around minute 7:38. While working with the AWS Policy Generator we are instructed to select the S3:DeleteObject action but to enter the arn of the Bucket (arn:aws:s3:::myacloudgurusecuritybucket) instead of a specific object or wildcard in the Amazon Resource Name field. Later on when the policy is created and we proceed to paste it into the Bucket Policy Editor the instructor comments that there’s an error in the policy generator because we are now forced to change the ARN in the editor by adding / at the end for us to be able to save it.
I wanted to point out that that behavior is not really an error. If we had selected the action S3:DeleteBucket instead of S3:DeleteObject for the exercise, the policy would have work without modification. But since we selected the S3:DeleteObject action we were supposed to enter an Object ARN in the Amazon Resource Name field of the Policy Generator, for example:
arn:aws:s3:::myacloudgurusecuritybucket/hello.txt (provided this file exists in the bucket
or
arn:aws:s3:::myacloudgurusecuritybucket/* (for all objects inside the bucket)
This way, the generated policy would be syntactically correct an no error would show up when saving it in the Policy Editor.
Maybe AWS should have the Policy Generator perform the same validation the Policy Editor does to detect that we are using an Object action on a Bucket resource.
1 Answers
If I may add on to Luis’ excellent comment, I wanted to point out some nuances to bucket policies. Using the DENY policy at 14:05 as an example, the policy states:
If any Principal attempts to perform any S3 action on any object in the myacloudgurusecuritybucket, deny access.
This does indeed have the effect of denying any sort of access to the objects in the bucket. It does NOT, however, limit access to the bucket itself, as the bucket is not specified in the Resource line.
Given this, if a Principal is allowed to perform bucket-level actions, either through IAM or the bucket policy itself, they can perform those actions even with this policy in place.
For example, if a Principal is allowed to perform s3:PutBucketPolicy, even with this policy on the bucket, they will be able to change the "Deny" effect to "Allow", and will give themselves (and everyone else in the world, for that matter), access to the objects in the bucket.
Side note: If you do set up a Deny all policy on the bucket, no user will be able to perform any bucket operations. If I recall correctly, most, if not all of the s3:*Object commands require at least s3:ListBucket, so that keeps you from performing any object operations as well. The root user of the account will be able to change the bucket policy, even if they can’t do anything else.