Amazon S3 is one of AWS' most common storage services for customers in addition to being integrated with a multitude of other AWS services. So it's worth devoting some time to see how S3 handles its own authorization mechanisms. There are multiple ways identities can be authorized to access an object within S3, some of which overlap with the IAM mechanisms we have already discussed. 

So how does a user or service get authorization to access S3 without using IAM policies? First, let's define the different methods that permissions can be applied from within S3.

• S3 bucket policies 
• And S3 ACLs, Access Control Lists

Bucket policies are similar to IAM policies, in that they allow access to resources via a JSON script. However, as the name implies, these bucket policies are only applied to buckets within S3 and act as resource-based policies, whereas IAM policies can be assigned to users, groups, or roles as we previously discussed, and are classed as identity-based policies.

When a bucket policy is applied, the permissions assigned apply to all objects within that bucket. This policy introduces a new attribute called principals. These principals can be IAM users, federated users, another AWS account, or even other AWS services, and it defines which principals should be allowed or denied access to various S3 resources. Principals are not used within IAM identity-based policies as the principal element is defined by who is associated to that policy via the user, group, or role association. As bucket policies are assigned to buckets, we need to have this additional parameter of principals within the policy to ensure the policy is being checked against the correct person or service.

As you can see from this example a bucket policy is very similar in terms of layout and syntax to that of an IAM policy. However, we do have the Principal attribute added. This value refers to the ARN of the principal, and in this example, we can see that it points to cloudacademy as a user within IAM, and this user is allowed to delete objects and put objects within the cloudacademy bucket identified under the resource parameter. 

S3 bucket policies also allow you to set conditions within the policy, allowing a fine-grain permission set to be defined. For example, you could allow or deny specific IP subnets to access the bucket, or perhaps even restrict a specific IP address. This is another level of access control taking place at the network level that helps to tighten access, ensuring only authorized access is permitted.

S3 Access control lists, or ACLs allow you to control access to buckets, in addition to specific objects within a bucket by groupings  and AWS accounts. One advantage of being able to use ACLs is that you can set different permissions per object.

ACLs do not follow the same JSON format as the policies defined by IAM and bucket policies. Instead, they are far less granular, and different permissions can be applied depending if you are applying an ACL at the bucket level or the object level.  Due to the basic structure of an ACL it is not possible to implicitly deny access using ACLs, neither are you able to implement conditional elements like we saw earlier when I mentioned identity-based access.  

An example of a default ACL for a bucket looks as shown. As you can see here, you can specify different permissions for different predefined S3 groups defined by the Grantee column.

Permissions are based on the Grantee, of which there are 4:

• The Bucket Owner, this will be your own AWS account and will have full control over all objects and the bucket itself
• Everyone (public access), permissions set against this grantee would mean anyone can access the content using the permissions applied, providing the object had been made public. These requests can be signed (authenticated) or unsigned (unauthenticated)
• Authenticated Users - This option will allow IAM users from any AWS account to access the object, via signed requests (authenticated)
• S3 Log delivery group - This is a group used to deliver log files when server access logs has been configured and the bucket is used to store and WRITE log files to

By editing the ACL at the bucket level you will be presented with the following.

This shows you the different levels of permissions that can be applied to the Bucket.  It will show you the permissions given to the grantee groups for the bucket, which are either List or Write. You can also see what permissions have been given to enable the grantees access to either Read or Write against the Bucket ACL.  

For clarification about what these permissions actually grant, they are as follows:

• List: (Allows the grantee to list objects in the bucket)
• Write: (Allows grantee to create, overwrite, and delete objects in the bucket)
• Bucket ACL Read (Allows the grantee to read the ACL of the bucket)
• Bucket ACL Write: (Allows the grantee to write the ACL for the bucket)

You may have noticed that you can also add access for another account as a Grantee.  To configure this access you will be required to enter the Canonical ID of the AWS account that you would like to have access.

So we have seen what the ACL Looks like at the Bucket level, let’s now take a quick look at what it looks like at the object level.  

Here is an ACL of an object within a bucket. 

As you can see, again by default the resource owner has full control over the object.  Also, you will also notice that you can add access for another account, again you will need to add the appropriate canonical AWS Account ID and the relevant permissions.

You can also specify Public access (if you have Public access enabled).  In this example, we can see that the ‘Everyone’ Group has Read access to the Object.  To modify this permission I could simply click on the radio button next to the group and modify the settings as shown: 

Note there is no WRITE permission when working with object ACLs, unlike Bucket ACLs.

Again, let’s take a closer look at what actual permissions are being applied depending on the option chosen for the object:

• Read Object: (Allows the grantee to read the object data and its metadata)
• Read object permissions: (Allows grantee to read the object ACL)
• Write object permissions (Allows the grantee to write the ACL for the object)

We have spoken about a number of ways an identity or principal can be authorized access to a resource or object within AWS, but what happens if a principal who belongs to an IAM group and accesses an object in a bucket with S3 ACLs, bucket permissions and their own IAM permissions? With all of this authorization, how is this access governed if there are conflicting permissions to the object in the bucket that they are trying to access?

Well, AWS handles this permission conflict in accordance with the basis of least privilege. Essentially, by default, AWS dictates that access is denied to an object, even without an explicit Deny within any policy. To gain access, there has to be an Allow within a policy that the principal is associated to or defined by within a bucket policy or ACL. If there are no Denies defined, but there is an Allow within a policy, then access will be authorized. However, if there is a single Deny associated with a principal to a specific object, then even if an Allow does exist, this explicit Deny will always take precedence, overruling the Allow, and access will not be authorized.