Understanding when to use S3 Bucket Policies versus S3 ACLs versus AWS IAM Policies can easily make your head spin. To make sense of it, we’ve created text-based and image-based cheat sheets (available at the end of this article). These cheat sheets are straight from our Introduction to AWS Security course.
First, let’s go through a quick explanation and summary of each.
S3 Bucket Policies
As the name implies, S3 Bucket Policies are applied directly to an S3 bucket to not only control bucket access but also to control specific object permissions for objects that reside within that bucket.
If you create a new S3 bucket and start uploading objects to that bucket, you’ll want to make sure they’re properly protected…but you’re uploading those objects for a specific purpose and that purpose may involve granting access to the objects to applications, services, or people.
In order to grant that access without making those objects or buckets public, you can create bucket policies.
S3 ACLs were one of the original security controls for S3 a few years back, but they are no longer recommended for most use cases since S3 Bucket Policies have replaced them as the best option for securing buckets and objects.
Only if you cannot solve your use case with bucket policies should you entertain using S3 ACLs.
AWS IAM Policies
IAM policies are applied to IAM users, groups, and roles, which helps provide centralized access management for AWS resources. They are not specific to S3, they are used to control access permissions across all of AWS.
While you can protect buckets and objects with bucket policies, those are applied to S3 buckets. What about when you create IAM users, groups, or roles, and you want to give those resources access to S3 resources? Not only could you do that with bucket policies, but you can also apply those permissions with IAM policies.
That means you can use S3 Bucket Policies in conjunction with IAM Policies for multiple layers of security.
For example, you may have granted permissions via S3 Bucket Policies, but as you create a new IAM role, you would want to attach an IAM policy to that role that grants access as well. Or vice versa — you might grant access to an object via an IAM policy attached to the role, but the Bucket Policy explicitly denies that access which means the role will not have access.
In general, avoid using S3 ACLs unless they are necessary. They’ve been mostly replaced by S3 Bucket Policies.
Use S3 Bucket Policies to set baseline security for specific buckets and their objects.
Use IAM Policies to grant users, groups, or roles access to AWS resources and services, including S3 buckets or objects.
Text-based Cheat Sheet
|S3 Bucket Policies||S3 ACLs||IAM Policies|
|Scope||Applied to an S3 bucket to control bucket access, but can also control specific object permissions||Applied to buckets or to an individual object. Older access control method that’s no longer recommended to use if it can be avoided||Applied to IAM users, groups, and roles across the AWS account|
|Syntax||JSON-based policies||XML-based policies written in a specific format||JSON-based policies|
|Flexibility||Provide granular control with powerful conditions and fine-grained permissions||Provide basic access control but have fewer options for advanced permissions||Provide centralized access management for various AWS services, not just S3|
|Permissions||Can define access controls for both bucket-level and object-level operations||Can define access controls for individual objects and bucket-level operations, such as ||Can define access controls for various AWS services, including S3, at a fine-grained level|
|Principal-Based||Identify the principal (role, user, group, or AWS account) and define their access permissions||Identify the user or group and define their access permissions||Define permissions for IAM users, groups, and roles by attaching policies to them|
|IAM Integration||Can reference IAM users, groups, and roles in policies to grant additional permissions or restrict access||Can use canonical user IDs to grant permissions to an AWS account (or even email addresses but they get converted to canonical user IDs), or can use a URI to grant permissions to a predefined group||Create and manage IAM policies separately from S3 bucket policies. IAM policies can be attached to IAM entities for S3 access control|
|Examples||Grant read access to all objects in a bucket to a specific IAM role||Grant write access to a specific object to an external AWS account user||Grant full access to an S3 bucket to an IAM group, while restricting delete permissions for specific IAM users|