Access control list (ACL) overview
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.
S3 Object Ownership is an Amazon S3 bucket-level setting that you can use to both control ownership of the objects that are uploaded to your bucket and to disable or enable ACLs. By default, Object Ownership is set to the Bucket owner enforced setting, and all ACLs are disabled. When ACLs are disabled, the bucket owner owns all the objects in the bucket and manages access to them exclusively by using access-management policies.
A majority of modern use cases in Amazon S3 no longer require the use of ACLs. We recommend that you keep ACLs disabled, except in circumstances where you need to control access for each object individually. With ACLs disabled, you can use policies to control access to all objects in your bucket, regardless of who uploaded the objects to your bucket. For more information, see Controlling ownership of objects and disabling ACLs for your bucket.
Important
If your general purpose bucket uses the Bucket owner enforced setting for S3 Object Ownership, you must use policies to
grant access to your general purpose bucket and the objects in it. With the Bucket owner enforced setting enabled, requests to set
access control lists (ACLs) or update ACLs fail and return the AccessControlListNotSupported error code.
Requests to read ACLs are still supported.
When you create a bucket or an object, Amazon S3 creates a default ACL that grants the resource owner full control over the resource. This is shown in the following sample bucket ACL (the default object ACL has the same structure):
Example
<?xml version="1.0" encoding="UTF-8"?> <AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <Owner> <ID>*** Owner-Canonical-User-ID ***</ID> </Owner> <AccessControlList> <Grant> <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Canonical User"> <ID>*** Owner-Canonical-User-ID ***</ID> </Grantee> <Permission>FULL_CONTROL</Permission> </Grant> </AccessControlList> </AccessControlPolicy>
The sample ACL includes an Owner element that identifies the owner by the
AWS account's canonical user ID. For instructions on finding your canonical user ID,
see Finding an AWS account canonical user ID. The
Grant element identifies the grantee (either an AWS account or a
predefined group) and the permission granted. This default ACL has one
Grant element for the owner. You grant permissions by adding
Grant elements, with each grant identifying the grantee and the
permission.
Note
An ACL can have up to 100 grants.
Topics
Who is a grantee?
When you grant access rights, you specify each grantee as a
pair, where type="value" is one of the
following:type
id– If the value specified is the canonical user ID of an AWS accounturi– If you are granting permissions to a predefined group
Warning
When you grant other AWS accounts access to your resources, be aware that the AWS accounts can delegate their permissions to users under their accounts. This is known as cross-account access. For information about using cross-account access, see Creating a Role to Delegate Permissions to an IAM User in the IAM User Guide.
Finding an AWS account canonical user ID
The canonical user ID is associated with your AWS account. This ID is a long string of characters, such as:
79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be
For information about how to find the canonical user ID for your account, see Find the canonical user ID for your AWS account in the AWS Account Management Reference Guide.
You can also look up the canonical user ID of an AWS account by reading the ACL of a bucket or an object to which the AWS account has access permissions. When an individual AWS account is granted permissions by a grant request, a grant entry is added to the ACL with the account's canonical user ID.
Note
If you make your bucket public (not recommended), any unauthenticated user
can upload objects to the bucket. These anonymous users don't have an
AWS account. When an anonymous user uploads an object to your bucket, Amazon S3
adds a special canonical user ID
(65a011a29cdf8ec533ec3d1ccaae921c) as the object owner in
the ACL. For more information, see Amazon S3 bucket and object ownership.
Amazon S3 predefined groups
Amazon S3 has a set of predefined groups. When granting account access to a group, you specify one of the Amazon S3 URIs instead of a canonical user ID. Amazon S3 provides the following predefined groups:
-
Authenticated Users group – Represented by
http://acs.amazonaws.com/groups/global/AuthenticatedUsers.This group represents all AWS accounts. Access permission to this group allows any AWS account to access the resource. However, all requests must be signed (authenticated).
Warning
When you grant access to the Authenticated Users group, any AWS authenticated user in the world can access your resource.
-
All Users group – Represented by
http://acs.amazonaws.com/groups/global/AllUsers.Access permission to this group allows anyone in the world access to the resource. The requests can be signed (authenticated) or unsigned (anonymous). Unsigned requests omit the Authentication header in the request.
Warning
We highly recommend that you never grant the All Users group
WRITE,WRITE_ACP, orFULL_CONTROLpermissions. For example, althoughWRITEpermissions deny non-owners the ability to overwrite or delete existing objects,WRITEpermissions still allow anyone to store objects in your bucket, for which you are billed. For more details about these permissions, see the following section What permissions can I grant?.