Did this page help you? Yes No Tell us about it...

Access Control List (ACL) Overview

Topics

Amazon S3 Access Control Lists (ACL) 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 the requester has the necessary access permissions.

When you create a bucket or an object, Amazon S3 creates a default ACL that grants the resource owner full control over the resource as shown in the following sample bucket ACL (the default object ACL has same structure).

<?xml version="1.0" encoding="UTF-8"?>
<AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <Owner>
    <ID>*** Owner-Canonical-User-ID ***</ID>
    <DisplayName>owner-display-name</DisplayName>
  </Owner>
  <AccessControlList>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Canonical User">
        <ID>*** Owner-Canonical-User-ID ***</ID>
        <DisplayName>display-name</DisplayName>
      </Grantee>
      <Permission>FULL_CONTROL</Permission>
    </Grant>
  </AccessControlList>
</AccessControlPolicy>

The sample ACL includes an Owner element identifying the owner via the AWS account's 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, identifying the grantee and the permission.

	Note
	An ACL can have up to 100 grants.

When you send a REST request to create a bucket or add an object, you cannot specify an ACL in the request body. However, Amazon S3 supports adding canned, predefined ACLs. Each canned ACL has predefined set of grantees and permissions. You specify a canned ACL in your request header and Amazon S3 adds the corresponding predefined grants to the resource ACL. For more information, see Canned ACL.

Specifying a Grantee

A grantee can be an AWS account or one of the predefined Amazon S3 groups. You grant permission to an AWS account by the email address or the canonical user ID. However, if you provide a email in your grant request, Amazon S3 finds the canonical user ID for that account and adds it to the ACL. The resulting ACLs will always contain the canonical user ID for the AWS account, not the AWS account's email address.

Amazon S3 has a set of predefined groups. When granting account access to a group, you specify one of our URIs instead of a canonical user ID. We provide the following predefined groups:

Authenticated Users group—Represented by http://acs.amazonaws.com/groups/global/AuthenticatedUsers.
This group represents all Amazon AWS accounts. Access permission to this group allows any Amazon AWS account to access the resource. However, all requests must be signed (authenticated).
All Users group—Represented by http://acs.amazonaws.com/groups/global/AllUsers.
Access permission to this group allows anyone to access the resource. The requests can be signed (authenticated) or unsigned (anonymous). Unsigned requests omit the Authentication header in the request.
Log Delivery group—Represented by http://acs.amazonaws.com/groups/s3/LogDelivery.
WRITE permission on a bucket enables this group to write server access logs (see Server Access Logging) to the bucket.

	Note
	When using ACLs, a grantee can be an AWS account or one of the predefined Amazon S3 groups. However, the grantee cannot be an IAM User. For more information about AWS users and permissions within IAM, go to Using AWS Identity and Access Management.

	Note
	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, go to Enabling Cross-Account Access in Using Identity and Access Management.

Finding a Canonical User ID

The canonical user ID is associated with your AWS account. You can find this ID as follows:

To find Canonical User ID

Go to Security Credentials.
If you are not already logged in, you are prompted to sign in to Amazon Web Services.
Go to the Account Identifier section for the canonical user ID associated with your AWS account.

You can also look up the canonical user ID of AWS accounts by reading the ACL of a bucket or an object to which the AWS account has access permissions. When individual AWS account is granted a permission, there is a grant entry in the ACL with the AWS account's canonical user ID.

Specifying a Permission

The following table lists the set of permissions Amazon S3 supports in an ACL. The table lists the permission and describes what they mean in the context of object and bucket permissions.

Permission	When granted on a bucket	When granted on an object
`READ`	Allows grantee to list the objects in the bucket	Allows grantee to read the object data and its metadata
`WRITE`	Allows grantee to create, overwrite, and delete any object in the bucket	Not applicable
`READ_ACP`	Allows grantee to read the bucket ACL	Allows grantee to read the object ACL
`WRITE_ACP`	Allows grantee to write the ACL for the applicable bucket	Allows grantee to write the ACL for the applicable object
`FULL_CONTROL`	Allows grantee the READ, WRITE, READ_ACP, and WRITE_ACP permissions on the bucket	Allows grantee the READ, READ_ACP, and WRITE_ACP permissions on the object

Sample ACL

The following sample ACL on a bucket identifies the resource owner and a set of grants. The format is the XML representation of an ACL in the Amazon S3 REST API. The bucket owner has FULL_CONTROL of the resource. In addition, the ACL shows how permissions are granted on resource to two AWS accounts, identified by canonical user ID, and two of the predefined Amazon S3 groups discussed in the preceding section.

<?xml version="1.0" encoding="UTF-8"?>
<AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <Owner>
    <ID>Owner-canonical-user-ID</ID>
    <DisplayName>display-name</DisplayName>
  </Owner>
  <AccessControlList>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
        <ID>Owner-canonical-user-ID</ID>
        <DisplayName>display-name</DisplayName>
      </Grantee>
      <Permission>FULL_CONTROL</Permission>
    </Grant>
    
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
        <ID>user1-canonical-user-ID</ID>
        <DisplayName>display-name</DisplayName>
      </Grantee>
      <Permission>WRITE</Permission>
    </Grant>

    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
        <ID>user2-canonical-user-ID</ID>
        <DisplayName>display-name</DisplayName>
      </Grantee>
      <Permission>READ</Permission>
    </Grant>

    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group">
        <URI>http://acs.amazonaws.com/groups/global/AllUsers</URI> 
      </Grantee>
      <Permission>READ</Permission>
    </Grant>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group">
        <URI>http://acs.amazonaws.com/groups/s3/LogDelivery</URI>
      </Grantee>
      <Permission>WRITE</Permission>
    </Grant>

  </AccessControlList>
</AccessControlPolicy>

Canned ACL

Amazon S3 supports a set of predefined ACLs, known as canned ACLs. Each canned ACL has a predefined a set of grantees and permissions. You specify a canned ACL in your request using the x-amz-acl request header. When Amazon S3 receives a request with a canned ACL in the request, it adds the predefined grants to the ACL of the resource. The following table lists the set of canned ACLs and the associated predefined grants.

Canned ACL	Applies to	Permissions added to ACL
`private`	Bucket and object	Owner gets `FULL_CONTROL`. No one else has access rights (default).
`public-read`	Bucket and object	Owner gets `FULL_CONTROL`. The `AllUsers` group ( see Specifying a Grantee) gets the `READ` access.
`public-read-write`	Bucket and object	Owner gets `FULL_CONTROL`. The `AllUsers` group gets `READ` and `WRITE` access. Granting this on a bucket is generally not recommended.
`authenticated-read`	Bucket and object	Owner gets `FULL_CONTROL`. The `AuthenticatedUsers` group gets `READ` access.
`bucket-owner-read`	Object	Object owner gets `FULL_CONTROL`. Bucket owner gets `READ` access. If specified when creating a bucket, Amazon S3 ignores it.
`bucket-owner-full-control`	Object	Both the object owner and the bucket owner get `FULL_CONTROL` over the object. If you specify this canned ACL when creating a bucket, Amazon S3 ignores it.
`log-delivery-write`	Bucket	The `LogDelivery` group gets `WRITE` and the `READ_ACP` permission on the bucket. For more information on logs, see (Server Access Logging).

The overview section (see Access Control List (ACL) Overview) describes how you can add a grant to an ACL. However, you can also add grant to the ACL of an existing object or a bucket. When creating an object or a bucket, you cannot specify an ACL. instead, you can specify the canned ACL.

	Note
	You can specify only one of these canned ACLs in your request.

How to Specify an ACL

There are several ways you can add grants to your resource ACL. Amazon S3 provides the following methods for you to set an ACL:

Set ACL using request headers— When you create a new resource (bucket or object), you can set an ACL using the request headers. You can set either a canned ACL or specify a set of permissions explicitly.
Set ACL using request body— On an existing resource, you can set an ACL using either the request headers or the body.

For more information, see Managing ACLs.

Document Conventions
Terms of Use

Did this page help you? Yes No Tell us about it...