Access Control List

Access Control List VK Cloud (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.

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).

Copy
<? xml version = "1.0" encoding = "UTF-8"?><AccessControlPolicy xmlns = "http: // <bucket_name> .hb.vkcs.cloud / 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 VK Cloud account.
• The <Grant> element identifies the recipient (VK Cloud 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.

The recipient of rights can be an VK Cloud project or one of the global VK Cloud groups. Rights can be granted to an VK Cloud 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 VK Cloud account
• uri is a predefined group to which permission is granted
• emailAddress - VK Cloud project ID

Example: project ID

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

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

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

It can be calculated using the command

Copy
aws s3api list-buckets --query Owner.ID --output text --endpoint-url https://hb.vkcs.cloud

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

Project ID (mcs_pid) - a unique parameter that characterizes a project on the VK Cloud 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.

Cloud Storage 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 VK Cloud accounts are represented in this group. Permission to access this group allows any VK Cloud account to access the resource. However, all requests must be signed (authenticated).

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.

The table lists the permission sets that Cloud Storage 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.

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 Cloud Storage 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.

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

Copy
<? xml version = "1.0" encoding = "UTF-8"?><AccessControlPolicy xmlns = "http: // <bucket_name> .hb.vkcs.cloud / 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>

Cloud Storage 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.

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