Access policy guidelines - Amazon Simple Storage Service

Access policy guidelines

Amazon S3 supports resource-based policies and user policies to manage access to your Amazon S3 resources. For more information, see Managing access to resources. Resource-based policies include bucket policies, bucket access control lists (ACLs), and object ACLs. This section describes specific scenarios for using resource-based access policies to manage access to your Amazon S3 resources.

When to use an ACL-based access policy (bucket and object ACLs)

Both buckets and objects have associated ACLs that you can use to grant permissions.

By default, when another AWS account uploads an object to your S3 bucket, that account (the object writer) owns the object, has access to it, and can grant other users access to it through ACLs. You can use Object Ownership to change this default behavior so that ACLs are disabled and you, as the bucket owner, automatically own every object in your bucket. As a result, access control for your data is based on policies, such as IAM policies, S3 bucket policies, virtual private cloud (VPC) endpoint policies, and AWS Organizations service control policies (SCPs).

A majority of modern use cases in Amazon S3 no longer require the use of ACLs, and we recommend that you disable ACLs except in unusual circumstances where you need to control access for each object individually. With Object Ownership, you can disable ACLs and rely on policies for access control. When you disable ACLs, you can easily maintain a bucket with objects uploaded by different AWS accounts. You, as the bucket owner, own all the objects in the bucket and can manage access to them using policies. For more information, see Controlling ownership of objects and disabling ACLs for your bucket.

Important

If your bucket uses the bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your bucket and the objects in it. Requests to set ACLs or update ACLs fail and return the AccessControlListNotSupported error code. Requests to read ACLs are still supported.

When to use an object ACL

The following are the scenarios when you would use object ACLs to manage permissions.

Objects are not owned by the bucket owner

An object ACL is the only way to manage access to objects that are not owned by the bucket owner. An AWS account that owns the bucket can grant another AWS account permission to upload objects. The bucket owner does not own these objects. The AWS account that created the object must grant permissions using object ACLs.

Note

A bucket owner cannot grant permissions on objects it does not own. For example, a bucket policy granting object permissions applies only to objects owned by the bucket owner. However, the bucket owner, who pays the bills, can write a bucket policy to deny access to any objects in the bucket, regardless of who owns it. The bucket owner can also delete any objects in the bucket.

You need to manage permissions at the object level

Suppose that the permissions vary by object and you need to manage permissions at the object level. You can write a single policy statement granting an AWS account read permission on millions of objects with a specific key name prefix. For example, you could grant read permission on objects starting with the key name prefix logs. However, if your access permissions vary by object, granting permissions to individual objects using a bucket policy might not be practical. Also, the bucket policies are limited to 20 KB in size.

In this case, you might find using object ACLs a good alternative. However, even an object ACL is also limited to a maximum of 100 grants. For more information, see Access control list (ACL) overview.

Object ACLs control only object-level permissions

There is a single bucket policy for the entire bucket, but object ACLs are specified per object.

An AWS account that owns a bucket can grant another AWS account permission to manage an access policy. Doing so allows that account to change anything in the policy. To better manage permissions, you might choose not to give such a broad permission, and instead grant the other account only the READ-ACP and WRITE-ACP permissions on a subset of objects. This limits the account to manage permissions only on specific objects by updating individual object ACLs.

If you want to use ACLs to manage permissions at the object level and you also want to own new objects written to your bucket, you can apply the bucket owner preferred setting for Object Ownership. A bucket with the bucket owner preferred setting continues to accept and honor bucket and object ACLs. With this setting, new objects that are written with the bucket-owner-full-control canned ACL will be automatically owned by the bucket owner rather than the object writer. All other ACL behaviors remain in place. To require all Amazon S3 PUT operations to include the bucket-owner-full-control canned ACL, you can add a bucket policy that allows only object uploads using this ACL.

Alternatives to using ACLs

In addition to an object ACL, there are other ways an object owner can manage object permissions:

  • If the AWS account that owns the object also owns the bucket, it can write a bucket policy to manage the object permissions.

  • If the AWS account that owns the object wants to grant permission to a user in its account, it can use a user policy.

  • If you, as the bucket owner, want to automatically own and have full control over every object in your bucket, you can apply the bucket owner enforced setting for Object Ownership to disable ACLs. As a result, access control for your data is based on policies. For more information, see Controlling ownership of objects and disabling ACLs for your bucket.

When to use a bucket ACL

The only recommended use case for bucket ACLs is to grant permissions to certain AWS services like the Amazon CloudFront awslogsdelivery account. When you create or update a distribution and enable CloudFront logging, CloudFront updates the bucket ACL to give the awslogsdelivery account FULL_CONTROL permissions to write logs to your bucket. For more information, see Permissions required to configure standard logging and to access your log files in the Amazon CloudFront Developer Guide. If the bucket that stores the logs uses the bucket owner enforced setting for S3 Object Ownership to disable ACLs, CloudFront cannot write logs to the bucket. For more information, see Controlling ownership of objects and disabling ACLs for your bucket.

When to use a bucket policy

If an AWS account that owns a bucket wants to grant permission to users in its account, it can use either a bucket policy or a user policy. However, in the following scenarios, you must use a bucket policy.

You want to manage cross-account permissions for all Amazon S3 permissions

You can use ACLs to grant cross-account permissions to other accounts. But ACLs support only a finite set of permissions, and these don't include all Amazon S3 permissions. For more information, see What permissions can I grant? For example, you can't grant permissions on bucket subresources. For more information, see Identity and access management in Amazon S3.

Both bucket and user policies support granting permission for all Amazon S3 operations. (For more information, see Amazon S3 actions.) However, the user policies are for managing permissions for users in your account. For cross-account permissions to other AWS accounts or users in another account, you must use a bucket policy.

When to use a user policy

In general, you can use either a user policy or a bucket policy to manage permissions. You can choose to manage permissions by creating users and managing permissions individually by attaching policies to users (or user groups). Or, you might find that resource-based policies, such as a bucket policy, work better for your scenario.

With AWS Identity and Access Management (IAM) you can create multiple users within your AWS account and manage their permissions through user policies. An IAM user must have permissions from the parent account to which it belongs, and from the AWS account that owns the resource that the user wants to access. The permissions can be granted as follows:

  • Permission from the parent account – The parent account can grant permissions to its user by attaching a user policy.

  • Permission from the resource owner – The resource owner can grant permission to either the IAM user (using a bucket policy) or the parent account (using a bucket policy, bucket ACL, or object ACL).

This is similar to a child who wants to play with a toy that belongs to someone else. To play with the toy, the child must get permission from a parent and permission from the toy owner.

For more information, see Bucket policies and user policies.

Permission delegation

If an AWS account owns a resource, it can grant those permissions to another AWS account. That account can then delegate those permissions, or a subset of them, to users in the account. This is referred to as permission delegation. But an account that receives permissions from another account cannot delegate permission cross-account to another AWS account.

We recommend that you first review all introductory topics that explain how you manage access to your Amazon S3 resources and related guidelines. For more information, see Identity and access management in Amazon S3. You can then use the following topics for more information about specific access policy options.