S3 Bucket Policies vs. ACLs vs. IAM Policies [Cheat Sheet]

S3 Access Control Cheat Sheet

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

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.

Summary

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 PoliciesS3 ACLsIAM Policies
ScopeApplied to an S3 bucket to control bucket access, but can also control specific object permissionsApplied to buckets or to an individual object. Older access control method that’s no longer recommended to use if it can be avoidedApplied to IAM users, groups, and roles across the AWS account
SyntaxJSON-based policiesXML-based policies written in a specific formatJSON-based policies
FlexibilityProvide granular control with powerful conditions and fine-grained permissionsProvide basic access control but have fewer options for advanced permissionsProvide centralized access management for various AWS services, not just S3
PermissionsCan define access controls for both bucket-level and object-level operationsCan define access controls for individual objects and bucket-level operations, such as READ, WRITE, READ_ACP, WRITE_ACP, and FULL_CONTROLCan define access controls for various AWS services, including S3, at a fine-grained level
Principal-BasedIdentify the principal (role, user, group, or AWS account) and define their access permissionsIdentify the user or group and define their access permissionsDefine permissions for IAM users, groups, and roles by attaching policies to them
IAM IntegrationCan reference IAM users, groups, and roles in policies to grant additional permissions or restrict accessCan 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 groupCreate and manage IAM policies separately from S3 bucket policies. IAM policies can be attached to IAM entities for S3 access control
ExamplesGrant read access to all objects in a bucket to a specific IAM roleGrant write access to a specific object to an external AWS account userGrant full access to an S3 bucket to an IAM group, while restricting delete permissions for specific IAM users

Downloadable image-based cheat sheet

Amazon S3 Cheat Sheet

Related Articles

Responses

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.