Написать в техподдержку Позвонить нам
Admin Panel Logout

In this article:

    Access Control List

    general information

    Access Control List MCS (ACL or Access Control List) allow you to control access to buckets and objects. Each bucket and object has its own ACL, with which you can determine which accounts and groups are granted access, as well as the type of access. When receiving a request for a resource, the service checks the corresponding ACL to see if the requestor has access rights.

    Note

    By default, the created bucket or object gets a Private ACL, where the owner has full rights, and the rest of the participants have access denied.

    When a container or object is created, the service creates a standard ACL that grants the resource owner full control over that resource and denies access to other projects. This is shown in the following bucket ACL example (the default object ACL has the same structure).

     <? xml version = "1.0" encoding = "UTF-8"?>
    <AccessControlPolicy xmlns = "http: // <bucket_name> .hb.bizmrg.com / images / 01.jpg /">
    <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 < Owner > element identifies the owner by the canonical user ID of the MCS account.
    • The < Grant > element identifies the recipient (MCS account or predefined group) and grants permission.

    The base ACL shown as an example defaults to one Grant element per owner. To grant permission, <Grant> elements are added, each <Grant> element must specify the grantor and permission options.

    Note

    ACLs can contain up to 100 permissions.

    Recipient of rights

    The recipient of rights can be an MCS project or one of the global MCS groups. Rights can be granted to an MCS project using the project ID address (mcs_pid) or the canonical user ID. Moreover, if you specify the project identifier in the request for access rights, then the service determines the canonical user ID for the corresponding project and adds it to the ACL. As a result, the ACL will always contain the canonical user ID for the project, not the project ID.

    To grant access rights, you must specify each recipient as a type = value pair, where type is one of the following:

    • id - the canonical user ID of the MCS account
    • uri is a predefined group to which permission is granted
    • emailAddress - MCS project ID

    Example: project ID

    For example, the x-amz-grant-read header grants MCS accounts identified by mcs_pid permissions to read object data and its metadata:

     x-amz-grant-read: emailAddress = "mcs1447309426", emailAddress = "mcs1380112926"

    Attention

    When granting other MCS accounts access to their resources, please note that MCS accounts can delegate their permissions to users under their own accounts. This is known as multi-account access.

    Canonical user ID

    The canonical user ID is associated with the MCS account. It's a long string like eab55955-ebdb-4f18-a94d-f3558ff150da.

    It can be calculated using the command

     $ aws s3api list-buckets --query Owner.ID --output text --endpoint-url https://hb.bizmrg.com

    You can also find the canonical user ID of the MCS account by reading the ACL of the bucket or object that the MCS account has access to. When an individual MCS account is granted permissions on a Grant request, a grant entry with the canonical user ID of the MCS account is added to the ACL.

    Note

    If you make your bucket public (not recommended), any unauthenticated user can upload objects to the bucket. These anonymous users do not have an MCS account. When an anonymous user uploads an object to a bucket, MCS S3 adds a special canonical user ID (65a011a29cdf8ec533ec3d1ccaae921c) as the owner of the object to the ACL.

    Project ID

    Project ID (mcs_pid) - a unique parameter that characterizes a project on the MCS platform. You can get it in your personal account in the account information area:

    The button located next to the project ID allows you to copy the parameter for convenience.

    Predefined groups

    MCS S3 has a set of predefined groups. When granting access to an account to a group, one of the URIs is specified instead of the canonical user ID. The following predefined groups are available:

    Authenticated Users - a group of authorized users, represented by http://acs.amazonaws.com/groups/global/AuthenticatedUsers.

    All MCS accounts are represented in this group. Permission to access this group allows any MCS account to access the resource. However, all requests must be signed (authenticated).

    Attention

    When granting access to the Authenticated Users group of users, any authorized MCS user from the Internet can access the resource.

    All Users - The All Users group, represented by http://acs.amazonaws.com/groups/global/AllUsers.

    Permission to access this group allows anyone on the Internet to access the resource. Requests can be signed (authenticated) or unsigned (anonymous). Unsigned requests omit the Authentication header in the request.

    Caution

    It is highly recommended that you do not grant permission to the All Users group with WRITE, WRITE_ACP, or FULL_CONTROL authority. For example, WRITE permissions allow anyone to store objects in a bucket, which is paid for by the current owner. It also allows others to delete objects that might need to be kept.

    Types of permits

    The table lists the permission sets that MCS S3 supports in the ACL. The ACL permission set is the same for object ACL and bucket ACL. These ACLs grant permissions for specific buckets or object operations. The table lists the permissions and describes what they mean in the context of objects and buckets.

    Resolution Applying to a bucket Applying to an object
    READ
    • HeadBucket
    • GetBucketLifecycle
    • GetBucketNotification
    • ListObjects
    • ListParts
    • ListMultiparts

    Allows you to get the content of an object and its metadata:

    • GetObject
    • HeadObject
    • GetObjectRange

    WRITE

    Allows you to create, delete, overwrite any objects in the bucket:

    • DeleteBucketNotification
    • PutBucketNotification
    • PutBucketLifecycle
    • DeleteBucketLifecycle
    • DeleteObject
    • DeletMultipleObjects
    • AbortMultipart
    • InitMultipart
    • UploadPart
    • CompliteMultipart
    • PutObject
    • PutObjectCopy
    Not applicable
    READ_ACP

    Allows reading the bucket ACL:

    • GetBucketAcl
    • GetBucketCors

    Allows reading the ACL of an object:

    GetObjectAcl


    WRITE_ACP

    Allows you to change the bucket ACL:

    • CreatePrefixKey
    • DeletePrefixKey
    • ListPrefixKeys
    • PutBucketCors
    • DeleteBucketCors
    • PutBucketAcl

    Allows changing the ACL of an object

    PutObjectAcl


    FULL_CONTROL Combines READ, WRITE, READ_ACP, WRITE_ACP permissions for bucket Combines READ, WRITE, READ_ACP, WRITE_ACP rights for an object

    Mapping ACL Permissions and Access Policy Permissions

    The ACL only allows a finite set of permissions compared to the number of permissions that can be set in the access policy. Each of these permissions allows one or more MCS S3 operations to be performed.

    The following table shows how each ACL permission maps to the corresponding access policy permissions. As you can see, the access policy allows more permissions than the ACL. ACL is used primarily to grant basic read and write permissions, similar to file system permissions.

    ACL permission Access policy for bucket Object access policy
    READ s3: ListBucket, s3: ListBucketMultipartUploads s3: GetObject
    WRITE s3: PutObject, s3: DeleteObject Not applicable
    READ_ACP s3: GetBucketAcl s3: GetObjectAcl
    WRITE_ACP s3: PutBucketAcl s3: PutObjectAcl
    FULL_CONTROL Equivalent to providing READ, WRITE,
    READ_ACP, and WRITE_ACP ACL permissions
    Equivalent to granting READ, READ_ACP, and WRITE_ACP ACL permissions

    Status keys

    When granting access policy permission, you can use conditional keys to restrict the ACL value for an object using a bucket policy. The following context keys correspond to ACLs. These context keys are intended to indicate the use of a specific ACL in a request:

    • s3: x-amz-grant-read - Read access
    • s3: x-amz-grant-write - Write rights
    • s3: x-amz-grant-read-acp - Access to read ACL bucket
    • s3: x-amz-grant-write-acp - Bucket ACL write permissions
    • s3: x-amz-grant-full-control - Full control
    • s3: x-amz-acl - Use a templated ACL

    ACL example

     <? xml version = "1.0" encoding = "UTF-8"?>
    <AccessControlPolicy xmlns = "http: // <bucket_name> .hb.bizmrg.com / images / 01.jpg /">
    <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>
    
    </AccessControlList>
    </AccessControlPolicy>

    Fixed ACL

    MCS S3 supports a set of predefined permissions known as standard ACLs. Each fixed ACL has a predefined set of recipients and permissions. The following table lists the standard ACLs and their associated predefined permissions.

    Fixed ACL Refers to Permissions added to ACL
    private Bucket and object The owner gets FULL_CONTROL. Nobody else has access rights (default).
    public-read Bucket and object The owner gets FULL_CONTROL. The AllUsers group gets READ access.
    public-read-write Bucket and object The owner gets FULL_CONTROL. The AllUsers group gets READ and WRITE access.
    aws-exec-read Bucket and object The owner gets FULL_CONTROL.
    authenticated-read Bucket and object The owner gets FULL_CONTROL. AuthenticatedUsers group gets READ access.
    bucket-owner-read An object The owner of the object gets FULL_CONTROL. The bucket owner gets READ access. If you specify this template ACL when creating a bucket, MCS S3 will ignore it.
    bucket-owner-full-control An object Both the object owner and the bucket owner get FULL_CONTROL over the object. If you specify this fixed ACL when creating a bucket, MCS S3 will ignore it.


    Note

    Only one of these fixed ACLs can be specified in a request.

    The request specifies a fixed ACL using the x-amz-acl request header. When MCS S3 receives a request with a standard ACL in the request, it adds the predefined permissions to the ACL of the resource.

    Was this article helpful?