Why can S3 permissions be managed by both IAM Policies and Bucket Policies, instead of just one or the other?

Question

I read https://aws.amazon.com/blogs/security/iam-policies-and-bucket-policies-and-acls-oh-my-controlling-access-to-s3-resources/, which to me answered the what and when, but not why.

I’m new to AWS and trying to learning it.

Why create two methods, and not just one? Based on the example in the article, why not just have IAM policy to handle both use cases, example like having IAM policy JSON include the ‘Principal’ entry as “base on association” or “??”, then it work like the Bucket policy. It look like for any services which require policy control will have another type of policy created. Example; YYY service policy will have a Principal and Action “YYY:”.

Reason I can think of is, S3 is where require lot of access control (like fine grain, grouping, etc..) and having a policy created specific S3 can ease management, and take less back-end resources?

Answer 1

S3 authorizes requests by testing all applicable authorities, in the "context" of user, bucket, and object.

See How Amazon S3 Authorizes a Request.

This document is confusing on first read, but it does give a better sense of what's happening with the multiple policies.

A few points to keep in mind:

• Users do not own buckets. Accounts own buckets, and accounts own users.
• If a user creates a bucket, the account that owns that user always owns that bucket.
• If a user creates an object, the account that owns that user always owns that object -- even if the bucket where the object was created is owned by a different account.

Wait, what?

If my account gives your user permission to create an object in my bucket, you would actually own the object. Unless you give me permission to read it, I can't read it. Since it's in my bucket, and I am paying to store it, I can delete it, but that's absolutely all I can do to that object unless you give me access to it.

So there are three levels of permissions at play -- things users are allowed to do (IAM policies), things accounts allow to be done to their bucket and their objects in that bucket (bucket policies and ACLs) and things accounts allow to be done to objects they own (object ACLs).

The default action is implicit deny, but anything my account has the authority to allow can be allowed by allowing it in any one place, as long as it isn't explicitly denied, elsewhere. Explicit deny will always deny, without exception.

Implications of the model:

• my user, my bucket, my object requires only one grant; access can be granted in any of the three places and only needs to be granted in one place, because my account owns all the resources... so I can do this in IAM policy, or bucket policy, or on the object.
• my user, your bucket requires two grants -- I allow my user in IAM policy, and you must allow my user in yout bucket policy. I don't have authority to do things to your bucket without your consent, and you don't have authority to allow my user to do things without my consent.
• it is possible to make my object in my bucket publicly readable via either the object ACL or via bucket policy, but not IAM policy, because IAM policies apply to users, and "everybody" is not one of my IAM users.

So, S3 needs multiple sources of grants becase of the permissions model. If you aren't doing anything cross-account, some of this would not be obvious since you would be unaware of some of the possible combinations.

My preference is for my bucket policies to require little attention. Users are given access in IAM, public objects are made public at the object level (you can do this in bucket policy, but I prefer it to be explicit at the object level), and so bucket policies have limited purpose -- sometimes there are bucket policy rules that deny access for all IP addresses except a list, usually the bucket policy denies uploads without AES-256 (so you can't "forget" to encrypt objects), and sometimes there are origin access identity rules for interoperating with CloudFront... but I do very little customization of bucket policies, because that's my design philosophy.