Skip to main content
ontaptom

1 year ago

Public Access to S3 files

Hi Everyone. I really enjoy 'Learn AWS by Doing', however I feel a bit confused by S3 permissions and Bucket Policies.   I understand I can make my whole bucket "public access", or a chosen resource with

"Resource": "arn:aws:s3:::bucket_name/my_object"


However, when I click on any of my objects and click 'make public' I think I would expect to this be added as a (autogenerated?) policy rule in my bucket policies. In other words, how can I control what object are made public if some  I can control by "make public" button, and others I can control by applying bucket policy?

Extra question :) I just made a test on my bucket, setting up the policy:


{
"Version": "2012-10-17",
"Id": "unique-id-to-describe-below-statement",
"Statement": [
{
"Sid": "unique-sid",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::tomek-learning-bucket/file1.txt"
}
]
}

Which is working as I would expect, only my file1.txt is available publicly , however AWS is flaging my whole bucket as "Public". Is that expected? It seems a bit confusing, bacause making single file public by clicking button "make public" doesn't flag my whole bucket as public, even though it has the same effect (or doesn't it?).

Additionally I clicked "make public" on file3.txt, which is also available publicly, but I cannot find the information in my S3 management console, that this specific file is public.  file2.txt is not public, and i have tested it, working as expected.

Yeah.. noob here, thanks for understanding.

Image of pzona
pzona
1 year ago

Great question! The "make public" button uses S3 access control lists, or ACLs, which are *officially* a legacy feature. The recommended way to do things is with a bucket policy, although ACLs are still widely used because they're much simpler and more straightforward.


So think of bucket policies and ACLs as separate services that are both evaluated when determining access to an object. They're separate in that changing one does not update the other (like you said), but they work together in a similar way to how IAM policies are evaluated. Explicit deny will overrule everything, then it will look for explicit allow, and anything that is not covered by either of those will be implicitly denied by default. For example, if you allow access to an object by clicking "Make Public" but deny access to that object in the bucket policy, the denial "wins" and the object is not public. There's not really a vice-versa scenario since bucket ACLs don't have an explicit deny, but hopefully that makes sense.


Here's a great blog post if you're curious about the exact steps in how these policies and ACLs are evaluated together, or when you might control access one way or the other: https://aws.amazon.com/blogs/security/iam-policies-and-bucket-policies-and-acls-oh-my-controlling-access-to-s3-resources/


For your second question, it looks like this is the expected behavior. The little "Public" flag shown in the console indicates that the bucket, or one or more of its objects, is accessible by either everyone in the world or any authenticated AWS user. Here's a caveat though - the permissions check that generates this label does not look at object ACLs, only the ACL of the entire bucket and the bucket policy. I want to draw attention to this because it means that you could technically have a bucket ACL that does not allow public access, but if you make one object public via ACL, the console flag will not be triggered.


To speak directly to your configuration, AWS is flagging it as public because the policy allows full access to an object to anyone in the world (from the line `"Principal": "*"`). Basically the thinking behind this is "better safe than sorry." If one object is completely open, they flag the bucket so you can check to make sure you're not doing something you didn't mean to. As for why object ACLs aren't evaluated in this, I assume that it has to do with how the underlying services are implemented.


If you're looking for more details about the little public flag in the console, check out: https://docs.aws.amazon.com/AmazonS3/latest/user-guide/bucket-permissions-check.html


Hope this helps clear things up. The different methods of access control in S3 can be tricky when you first get into them, don't hesitate to let us know if you have other questions!


Image of ontaptom
ontaptom
1 year ago
Phil - great answer.  Indeed with Your explaination, when I studied closer my ACL tab for each file I see how I can recognize files that have 'Everyone/read' access. Also, very useful blog posts, thanks!