S3 Access Management

Fortunately, Amazon S3 offers a comprehensive suite of tools and mechanisms to effectively control and manage access to objects within a bucket, empowering users to implement security measures and protect their data in the cloud environment. Let’s dive in to learn more about these.

IAM user policies

IAM policies are JSON or YAML-based policies that help us control users' access to AWS services and resources. For example, the policy below allows fetching objects from the S3 bucket named my-bucket. If we attach it to a user, the user can have access to all objects in my-bucket.

These permissions can be attached to the users, groups, and roles allowed to access the bucket’s objects. Although IAM policies are simpler to manage when controlling access to multiple buckets, managing them for cross-account users can be difficult as we would need other IAM resources besides the policies.

Similarly, if we want to give access to external identities, we cannot attach any IAM permissions or roles to them.

To cater to these limitations and manage access permissions at the resource level, we have resource-based policies.

Resource-based policies

A resource-based policy defines the permission to access a resource in AWS. Multiple AWS services allow us to define and attach a policy to the resource that determines the permitted actions, users, and services. Buckets also have resource-based policies defining which users’ services can add, delete, or update objects in a bucket.

The policy snippet below is a bucket policy that allows getting objects from the bucket named my-bucket.

The bucket policy looks similar to the IAM policy. However, notice the Principal element on lines 8–10. It determines who the policy applies to and distinguishes resource-based policy from other IAM policies. This policy only allows the IAM user my-user to access the bucket. We can allow external entities to access the bucket by using a wildcard in the principal element such as shown below:

To make our permissions more granular, we can use conditions. For example, the policy shown below allows the IAM user to get objects from my-bucket only if the request comes from a specific IP address.

We can use both IAM policies and bucket policies simultaneously to control access. The ultimate authorization is the least privileged union between both policies.

Access grants

As the user base and number of prefixes in a bucket increase, it can become difficult to manage access permissions. For example, if we have a data lake consisting of multiple folders accessed by multiple resources, it can be difficult to add policies to the bucket for each user group. Also, creating IAM roles for each user group can be difficult to manage. Besides, the maximum limit for IAM policies is 200 KB.

To cater to these limitations, S3 has released a new access mechanism called S3 Access Grants. S3 Access Grants refer to the permissions and privileges assigned to different entities, such as users, groups, or services, to perform specific actions on S3 buckets and objects. They manage access permissions at a more granular level and support corporate directories.

Access Grants can give up to 100,000 grants per Access Grants instance. An Access Grants instance is a logical grouping of all the access grants we have given. Each access grant has a grant scope, which can be a prefix in a bucket, an object, or an entire S3 bucket. Also, it defines grantee ID and grantee type, which can be any IAM entity or directory group. The permissions can be read-only, write-only, and read-write.

Access Control Lists (ACLs)

Access Control Lists are attached to the S3 buckets and their objects as a sub-resource to define the allowed users and allowed actions. We can define separate ACLs for the buckets and each object in the bucket. The sample ACL below grants read and write permissions to the bucket owner and read permissions to the AWS account with a specific canonical user ID.

The Grant element determines the grantee of the policy. A Grantee can be an AWS account or an Amazon S3 group allowed to access the bucket. We can grant permission using the email address or canonical user ID.

Access control lists predate the IAM permissions and are rarely used in modern applications. They are less flexible as compared to bucket policies. ACLs grant five basic permissions:

These five permissions cannot cover all the use cases. For example, we can not use ACL to give a user permission to write objects to the bucket but not delete them.

S3 provides another class of predefined ACLs called canned ACLs. A canned ACL is a pre-configured access settings that define the permissions for the bucket or object without the need for specifying individual grants or permissions. Examples of canned ACLs include bucket-owner-full-control, public-read and more.

ACLs are disabled by default and are generally discouraged by AWS. However, ACLS can be useful when managing access to individual files where using a bucket policy might not be convenient. They can be quickly enabled and rolled back.

Block public access

S3 buckets have a configuration called Block Public Access that enables us to manage access to buckets, access points, and accounts. This feature adds another layer of security to the bucket and applies to the external entities as well. By default, the block public access is enabled. Therefore, new buckets, access points, and objects do not allow public access. Block public access provides four settings to manage access. We can apply these settings to buckets, users, and access points:

• BlockPublicAcls: This setting does not allow to PUT a public bucket and object ACL. Also, it does not allow to PUT an object with a public ACL.

• IgnorePublicAcls: This setting ignores all the public ACLs on buckets and their objects. However, it allows to PUT objects with public ACLs.

• BlockPublicPolicy: This setting does not allow setting up any bucket or access point policy that allows public access.

• RestrictPublicBuckets: If a bucket has a public access policy, this setting allows public access to only AWS service principals and authorized users within the bucket owner's account and access point owner's account.

We can configure these settings in any combination or disable block public access entirely.

Block Public Access Settings override bucket policies, access point policies, or object permissions to allow public access. This means that through Block Public Access settings administrator can get centralized control of a bucket as these settings apply regardless of S3 resource settings.

Authorization while using multiple access control mechanisms

We can use all the access control mechanisms discussed above on a single S3 bucket to cater to various access management use cases. The ultimate access is determined based on the rule of least privilege. According to the rule of least privilege, a DENY precedes an ALLOW. If an action is denied according to any control mechanisms, it would have precedence over the ALLOW of another access control mechanism.

Additionally, the first step S3 takes while granting access is checking the Block Public Access setting of the bucket. If the request is made through an access point, then the block public access setting of the access point is also evaluated. The request is rejected if the Block Public Access setting denies the corresponding action. The following flowchart provides an overview of the factors influencing access when employing multiple access mechanisms.