Concepts
An ACL is described in the XML language. It is a list of specified grantees and permissions granted, which is associated with resources. Each bucket and object has an associated ACL to grant basic read and write permissions to anonymous users or other Tencent Cloud root accounts.
Note:
There are some limitations when managing resources using associated ACLs:
The resource owner always has the FULL_CONTROL permission on the resource, which cannot be revoked or modified.
An anonymous user cannot be the resource owner. In this case, the object owner is the bucket owner (Tencent Cloud root account).
Permissions can only be granted to Tencent Cloud CAM root accounts or preset user groups, but not custom user groups. Besides, it's not recommended to grant permissions to any sub-users.
No conditions should be imposed on the permissions.
"Deny" permission is not supported.
A resource can have up to 100 ACL policies.
Scenarios
Note:
Enabling anonymous access (Public Read) is highly risky due to hotlinking risks. In cases where Public Read is required, you can set hotlink protection to improve security. Use ACLs if you only need to set some simple access permissions for buckets and objects or enable anonymous access. However, in most cases, you are advised to use bucket policies or user policies, which are more flexible. ACLs are recommended in scenarios where you want to:
Set simple access permissions.
Set access permissions quickly in the console.
Make an object, directory, or bucket accessible to all anonymous internet users.
ACL Elements
Identity (Grantee)
A supported grantee can be a CAM root account or a preset CAM user group.
Note:
When you grant access permissions to another Tencent Cloud root account, this root account can grant access permissions to its sub-users, user groups or roles.
In COS, it is strongly recommended not to grant the WRITE, WRITE_ACP or FULL_CONTROL permission to any anonymous user or CAM user group. Otherwise, the user group can upload, download or delete your resources, which will bring security risks to your account, such as data loss and fee deduction.
Grantees supported in bucket or object ACLs include:
Cross-account: Please use the root account ID, which can be obtained from Account Center under Account Information, for example, 100000000001. Preset user group: tag a preset user group using a URI tag. The following user groups are supported:
Anonymous user group - http://cam.qcloud.com/groups/global/AllUsers This group represents that anyone can access resources without authorization, regardless of whether the request is signed or unsigned.
Authenticated user group - http://cam.qcloud.com/groups/global/AuthenticatedUsers This group represents that all users authenticated by Tencent Cloud CAM can access resources.
Action permissions
Tencent Cloud COS supports a range of action sets on resource ACLs, which include different actions on bucket ACLs and object ACLs respectively.
Actions on buckets
Here is a list of actions supported in bucket ACLs:
|
| | HeadBucket,GetBucketObjectVersions,ListMultipartUploads |
| Uploads, overwrites and deletes objects | PutObject,PutObjectCopy,PostObject,InitiateMultipartUpload, UploadPart,UploadPartCopy,CompleteMultipartUpload, DeleteObject |
| Reads the ACL for the bucket | |
| | |
| A collection of the above sets | A collection of the above action sets |
Note:
Please proceed with caution when you grant the WRITE, WRITE_ACP or FULL_CONTROL permission on buckets. Granting the WRITE permission will allow the grantee to overwrite or delete any existing object.
Actions on objects
Here is a list of actions supported in object ACLs:
|
| | GetObject,GetObjectVersion,HeadObject |
| | GetObjectACL,GetObjectVersionACL |
| | PutObjectACL,PutObjectVersionACL |
| A collection of the above sets | A collection of the above action sets |
Note:
The WRITE action set is not supported for objects.
Preset ACL
Tencent Cloud COS supports a group of preset ACLs for authorization, making it much easier to describe simple permissions. When using a preset ACL for description, you need to put the x-cos-acl header in the PUT Bucket/Object or PUT Bucket/Object ACL and describe the required permission. If an XML description is also carried in the request body, the description in the header is used and the XML description in the request body is ignored.
Preset ACLs for buckets
|
| The creator (root account) has the FULL_CONTROL permission, while others have no permissions. (Default) |
| The creator has the FULL_CONTROL permission, and the anonymous user group has the READ permission. |
| Both the creator and the anonymous user group have the FULL_CONTROL permission, which is generally not recommended. |
| The creator has the FULL_CONTROL permission, and the authenticated user group has the READ permission. |
Preset ACLs for objects
|
| An empty description. The explicit settings of each level of directory and the settings of the bucket are used to determine whether a request is allowed. (Default) |
| The creator (root account) has the FULL_CONTROL permission, while others have no permissions. |
| The creator has the FULL_CONTROL permission, and the anonymous user group has the READ permission. |
| The creator has the FULL_CONTROL permission, and the authenticated user group has the READ permission. |
| The creator has the FULL_CONTROL permission, and the bucket owner has the READ permission. |
bucket-owner-full-control | Both the creator and the bucket owner have the FULL_CONTROL permission. |
Note:
The public-read-write permission is not supported for objects.
Sample
Bucket ACL
When you create a bucket, COS creates a default ACL to grant the resource owner the full control over the resource (FULL_CONTROL), as shown in the following example:
<AccessControlPolicy>
<Owner>
<ID>Owner-Cononical-CAM-User-Id</ID>
</Owner>
<AccessControlList>
<Grant>
<Grantee>
<ID>Owner-Cononical-CAM-User-Id</ID>
</Grantee>
<Permission>FULL_CONTROL</Permission>
</Grant>
</AccessControlList>
</AccessControlPolicy>
Object ACL
When you create an object, COS does not create an ACL by default, and the object owner is the bucket owner. The object's permissions inherited from its bucket are the same with the access permissions of the bucket. Since the object does not have a default ACL, it will follow the definition of visitors and behaviors in the bucket policy to determine if the request is granted. For more information, see Access Policy Language Overview. If you need to grant additional access permissions to the object, you can add more ACLs to describe the access permissions of the object. For example, grant an anonymous user the permission to read a single object, as shown below:
<AccessControlPolicy>
<Owner>
<ID>Owner-Cononical-CAM-User-Id</ID>
</Owner>
<AccessControlList>
<Grant>
<Grantee>
<ID>Owner-Cononical-CAM-User-Id</ID>
</Grantee>
<Permission>FULL_CONTROL</Permission>
</Grant>
<Grant>
<Grantee>
<URI>http://cam.qcloud.com/groups/global/AllUsers</URI>
</Grantee>
<Permission>READ</Permission>
</Grant>
</AccessControlList>
</AccessControlPolicy>
Usage Guide
Using the Object Storage Console
Configure Bucket Access Permissions
You can use the COS console to set or modify bucket access permissions of the following two types.
Public permissions: Include private read/write, public read/private write and public read/write. For more information, see Types of Permission under Bucket Overview. User ACLs: The root account has all bucket permissions (full control) by default. You can add sub-accounts and grant them permissions including read/write, read/write ACL, and even full control.
Note:
If the bucket permission is private read/write or a specified account is granted the permission, an object request needs to carry a signature for identity verification. For more information on signature, see Request Signature. If the bucket permission is public read/private write or public read/write, an object request doesn't need to carry a signature, and anonymous users can directly access the object at the URL. However, your data may be leaked. Therefore, proceed with caution.
Granting Permissions for a Single Bucket
2. On the left sidebar, click Bucket List.
3. Locate the bucket for which you want to set or modify access permissions, and then click the bucket name.
4. Select Permission Management > Bucket ACL (Access Control List) and you can set both public permissions and user ACLs for the bucket. For example, you can add a sub-account, whose ID can be viewed in the CAM console. Note:
If you must use public read/private write or public read/write permissions and have not configured default alerts, it is recommended to enable an alarm policy. If already configured, there is no need to configure and no prompts will be given.
5. Click Save.
Granting Permissions for Multiple Buckets
2. On the left sidebar, click Bucket List.
3. Click Manage Permissions above the bucket list.
4. In the pop-up window, select the buckets that you want to grant permissions for. Then, scroll down to set both public permissions and user ACLs. For example, you can add a sub-account, whose ID can be viewed in the CAM console. Note:
Authorization management will modify both public permissions and user permissions simultaneously.
If you only need to modify user permissions, please ensure that the public permissions of your previous bucket and the current configuration are consistent; otherwise, it will override the previous permissions.
5. Once completed, click OK.
Configuring Object Access Permissions
COS allows you to set object access permissions, which have a higher priority than those for buckets.
Note:
Object access permissions take effect only when the access is made via the default endpoint. For any access made via a CDN acceleration endpoint or a custom endpoint, bucket access permissions will take effect.
Directions
2. In the left sidebar, click Bucket List to go to the bucket list page.
3. Locate the bucket where the object resides and click the bucket name to go to the bucket management page.
4. In the left sidebar, choose File List to go to the file list page.
5. Locate the object for which you want to configure the access permission, and click Details on the right to go to the file details page (If it is a folder, click Permissions on the right).
6. In the Object ACL(Access Control List) area, configure access permissions as needed.
COS supports two types of permissions for objects:
Public Permission: includes Inherit, Private Read/Write, and Public Read/Private Write. For more information about public permissions, please see Access Permission Types. User ACL: The root account has all object permissions (full control) by default. You can also add sub-accounts and grant them permissions including read/write, read/write ACL, and even full control.
7. Click Save.
If you need to configure or modify access permissions for multiple objects at a time, you can select the objects on the File List page and then click Modify Access Permission from the More Actions drop-down list at the top.