AWS S3 Security

An Introductory blog to compare S3 Security Policies

In the journey of learning AWS, the knowledge of applying proper security policies is very important while doing your AWS projects and even while passing your AWS certifications. There are so many permutations that you need to keep in mind while applying those policies in the real world AWS projects. This is an introductory blog, which will be useful for you to compare S3 security policies at a very high level.

P.Note: If you are sitting for AWS associate level certifications, this blog will help you.

S3 Security — An Introduction

All newly created S3 buckets are private by default. That means they are blocked for public access by default.

The only identity, which has the initial access to a newly created S3 bucket is the AWS account, which the S3 bucket was created.

The owner of S3 resources is always the AWS account that they belong to. Even if the S3 resources were created by any other IAM user, the owner of that resource still remains with the AWS account.

If any permissions to be granted to the S3 bucket, then they need to be explicitly defined. There are multiple way to do this.

1. Bucket Policy
2. Identity Policy
3. Access Control Lists (ACLs)

Bucket Policies and Identity Policies

Bucket policy is a form of a “resource policy”, which is attached to a resource instead of an identity that you find in identity policies. It basically controls “who” can access the particular resource, whereas in identity policies it controls “what” that identity can access.

In theory, there are two main differences between a bucket policy and an identity policy.

1. Granting access to multiple AWS accounts — With an identity policy you can assign permissions to identities within your AWS account only, unlike a resource policy can reference multiple identities from different AWS accounts. This is a great benefit for resource policies.
2. Anonymous access to a bucket — Bucket resource policies can grant “anonymous access” to the outside world unlike an identity policy which is always attached to an identity.

The “Principal” part of the S3 bucket resource policy basically specifies which identity is involved with the bucket. You may “not” find the “Principal” part in a typical identity policy simply because the identity policy is written to a given identity and there is no need to mention it.

Lets see a simple example to see how we can use both the IAM policy and the S3 bucket resource policy in cohesion. Lets create two IAM users (lets name them as dilhan and mithum)

1. Create the following IAM policy and attach it to mithum. (See figure 01)
2. Create a S3 bucket named as agasthimithum and create a S3 bucket policy and attach to it (See figure 02). Please do not forget to upload some files to it as well for further testing.
3. You may now sign in with both dilhan and mithum and try to browse S3 buckets. You will see only mithum is able to see the S3 bucket listing and on top of that he can go into the agasthimithum bucket and even open any files uploaded to it.

The IAM policy (See figure 01) will let AWS know that the particular IAM user (mithum) is able to list all buckets under S3 and even can list the contents of the agasthimithum bucket.

Figure 01 — IAM Identity Blocking the public accessPolicy

The S3 bucket policy (see figure 02) will further make sure the IAM user mithum is able to open files within the agasthimithum bucket.

Figure 02 — S3 Bucket Policy

As you can see now, the above two IAM and S3 bucket policies are working together to control the permissions. The final set of permission is a combination of both the identity policy and bucket policy (See figure 03).

Figure 03 — Policy Formulation

The Anonymous Access in a bucket policy

As explained, a bucket policy can grant anonymous access to outside world. By just specifying Principal: “*” in the bucket policy this could easily be achieved (See Figure 04).

Figure 04 — The bucket policy anonymous access

Access Control Lists (ACLs)

Amazon S3 Access Control Lists (ACLs) enable you to manage access to buckets and objects. Each bucket and object has an ACL attached to it as a subresource. It defines which AWS accounts or groups are granted access and the type of access. When a request is received against a resource, Amazon S3 checks the corresponding ACL to verify that the requester has the necessary access permissions.

However, ACLs are considered as legacy and primarily being replaced by S3 bucket policies. Its usage is limited nowadays largely due to its inflexibility compared to the bucket policies, which can do better. For example, ACLs cannot have conditional statements like you find in bucket policies.

Blocking the public access

To ensure the maximum security to S3 buckets, recently AWS added the “block public access” feature. By default this is enabled to make sure any mistakes done during bucket configurations by the implementer.

Conclusion

In summary, there is no hard and fast rule to stick to either identity or resource policy. We can leverage both on different situations. For example, if your S3 permission depends on multiple AWS accounts, then it is always need to use bucket policies. If you are inside a single AWS account, then it is always better to use IAM policies mainly because it is easy to manage multiple resources from a single identity policy. Otherwise, we probably need to write multiple resource / bucket policies for the situation. In addition to that, all the resources may not have the ability to define resource policies, that would prompt you to be with identity policies.

Sometimes, you may have to have both identity policies and resource policies need to be defines in combination to achieve certain use cases (as discussed in the blog).

References

1. Access Control Lists Overview — https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html