You can use a bucket policy to grant the operation permissions of a bucket and the objects in the bucket to CAM sub-accounts, other root accounts, and even anonymous users.
Overview
Note:
A Tencent Cloud root account has the highest permission on its resources (including buckets). Even if you can set limits on almost all operations in the bucket policy, the root account always has the permission for the PUT Bucket Policy operation, and can call this operation without checking the bucket policy.
A bucket policy is described in JSON language, and supports granting anonymous identities or any Tencent Cloud CAM account the permissions to access and perform operations on buckets and objects. In Tencent Cloud COS, the bucket policy can be used to manage almost all operations in the bucket. It is recommended that you use a bucket policy to manage access policies that cannot be described using ACLs. Scenarios
Note:
The permissions for the service-level operations of creating a bucket and querying a bucket list must be configured in the CAM console. If you want to specify which users can access a COS bucket, you are advised to configure a bucket policy. You can search for a bucket and check the bucket's policy to see who can access the bucket. A bucket policy is recommended in scenarios where you want to:
Authorize a specific bucket.
Use higher flexibility than that of an ACL.
Use cross-account authorization and anonymous user authorization, which are not supported by user policies.
Bucket Policy Elements
Bucket policies are described in JSON language and follow the syntax of the Access Policy Language, which includes basic elements such as principal, effect, action, resource, and condition. For more information, see Access Policy Language Overview.
In a bucket policy, the resource scope is limited to the bucket itself, and permissions can be granted for the entire bucket, specific directories, or specific objects. Note:
When adding a bucket policy, please ensure that you grant permissions according to your business needs and follow the principle of least privilege. If you directly grant other users access to all resources (resource:*) or all operations (action:*), there is a risk of data security due to excessively broad permissions.
Console Configuration Examples
Note:
When configuring a bucket policy in the COS console, you need to grant users appropriate permissions to the bucket, for example, the permissions to get bucket tags and list bucket permissions.
The bucket policy size is limited to 20 KB.
For example, if you want to grant a sub-account all permissions of a specified directory in a bucket, the corresponding configuration is as follows:
|
| |
| UIN of the sub-account, which must be a sub-account under the current root account, such as 100000000011 |
| Specified directory prefix, such as folder/sub-folder/* |
| |
| |
Visual Editor
Navigate to the Permission Management of the target bucket, select Policy Permission Settings > Graphical Settings, and click Add Policy to configure the policy in the pop-up window.
Step 1: Select a template (optional)
COS provides you with different templates depending on the combination of authorized users (grantees) and resource scope you choose to help you quickly configure bucket policies. If the templates provided by COS do not meet your requirements, you can skip this step and add or delete authorized operations in Step 2: configure the policy. Authorized Users
All users (anonymous access): Select this option when you want to grant operation permissions to anonymous users. In the next step to configure the policy, all users will be automatically added, represented as *.
Since listing objects (GetBucket) and granting bucket configuration permissions to anonymous users pose relatively high risks, COS does not provide a corresponding template when this option is selected. If required, you can manually add it in the subsequent "Configure Policy" procedure.
When the authorized user is set to all users (anonymous access allowed), no need to carry a signature when requesting an object. All users can directly access the object through the link. Your data may be at risk of leakage. Set with caution.
Select Deny all users can only deny anonymous users and will not deny CAM users. If needed to deny sub-accounts, select specified user in the bucket policy and designate the specific sub-account UIN.
Specify User: Choose this option when you want to grant operation permissions to a specific sub-account, root account, or cloud service. In the next step of configuring the policy, you will need to further specify the account UIN.
Note:
When the authorized user is a specified account, the requested object must carry a signature for identity authentication. For signature details, please refer to Request Signing. Resource Scope
Entire bucket: Choose this option when you want to grant permissions related to bucket configurations or specify the resource scope as the entire bucket. In the second step of policy configuration, the entire bucket will be automatically added as a resource.
Specified Directory: Choose this option when you want to limit the scope of resources to a specific folder. In the second step of configuring the policy, you will need to further specify the exact directory.When this option is selected, COS does not offer a bucket configuration policy template because such permissions must specify the entire bucket as the resource.
Template
The set of operations you wish to authorize. Based on the selected authorized users and resource scope, COS provides recommended policy templates for you. If the template does not meet your requirements, you can skip this step or add or remove authorized operations in the next step, "Configure Policy".
Custom policy (no preset configuration): If you do not need to use a template, you can choose this option and add policies according to your needs in the second step, "Configure policy."
Other templates: Based on the different combinations of authorized users and resource scopes you choose, COS provides various recommended templates. When you select the appropriate template, COS will automatically add the corresponding operations in the second step of policy configuration.
Templates are described in the following table:
|
All combinations |
| Custom Policy | For any combination of authorized users and resource scopes, this template does not provide any preset policies. You can add policies during policy configuration in step 2. |
All users (allow anonymous access) | The whole bucket | Read-Only objects (listing objects is not included) | For anonymous users, COS provides you with recommended templates for reading files (such as downloading files) and writing files (such as uploading and modifying files).COS's recommended templates do not list all objects in your bucket, and sensitive permissions, such as read and write permissions and bucket configuration permissions, are not allowed to improve data security. You can add or delete operation permissions during policy configuration in step 2 as needed. |
|
| Read/Write objects (listing objects is not included) |
|
| Specified directory | Read-Only objects (listing objects is not included) |
|
|
| Read/Write objects (listing objects is not included) |
|
Specified user | The whole bucket | Read-Only objects (listing objects is not included) | For specific users and entire bucket combinations, COS provides the most recommended templates. In addition to reading, writing, and listing files, COS also includes the following sensitive permission templates, suitable for trusted users: Read and write bucket and object ACLs: Retrieve and modify bucket ACLs and object ACLs, including GetObjectACL, PutObjectACL, GetBucketACL, and PutBucketACL. General bucket configurations include non-sensitive permissions such as bucket labels, cross-origin, and origin retrieval. Sensitive bucket configurations: Use caution when dealing with sensitive permissions, such as bucket policies, bucket ACLs, and bucket deletion. |
|
| Read-Only objects (listing objects is included) |
|
|
| Read/Write objects (listing objects is not included) |
|
|
| Read/Write objects (listing objects is included) |
|
|
| Read/Write buckets and object ACLs |
|
|
| General bucket configuration items |
|
|
| Bucket sensitive configuration item |
|
| Specified directory | Read-Only objects (listing objects is not included) | For the combination of Specified user and Specified directory, COS provides you with recommended templates for reading files (such as downloading files) and writing files (such as uploading and modifying files), as well as recommended templates for listing objects.If you need to grant read, write, and list permissions to a specified folder to a specified user, this combination is recommended.You can add or delete operation permissions during policy configuration in step 2 as needed. |
|
| Read-Only objects (listing objects is included) |
|
|
| Read/Write objects (listing objects is not included) |
|
|
| Read/Write objects (listing objects is included) |
|
Based on the combination of authorized users, specified directories, and templates you select in step 1, COS automatically adds operations, authorized users, and resources to the configuration policy for you. If you specify a user and a directory, you need to specify the user UIN and directory during policy configuration.
Note:
Please note that when authorizing a directory, you need to add /* at the end of the resource path. For example, to authorize the directory "test", you should enter test/*.
When the recommended templates provided by COS do not meet your requirements, you can also adjust the policy content in this step by adding or deleting authorized users, resources, and operations.
The configuration items are described as follows:
Effect: Supports selecting Allow or Deny, corresponding to "allow" and "deny" in the policy syntax.
User: Supports adding and deleting authorized users, including all users (*), root accounts, sub-accounts, and cloud services.
Note:
When Effectiveness is set to permission, the effective scope for all users includes anonymous users, sub-accounts, root accounts, and other users.
When Effect is set to Deny, the all users effective scope only targets anonymous users. Anonymous users will be unable to access the bucket. Proceed with caution.
Resource: add the whole bucket or a specific directory resource.
Operation: Add or delete authorized operations as needed.
Note:
IP IP and VPC ID VPC ID in conditions cannot be configured concurrently in the same policy. Please add policies separately.
If you use a CVM and a COS bucket in different regions or a non-CVM, select the condition as IP and fill in the public IP. If you use a CVM and a COS bucket in the same region, select the condition as VPC ID and fill in the VPC ID address.
Policy Syntax
In addition to using graphical configuration, users familiar with bucket policies can directly write policies.
After writing the bucket policy, click Save just. As shown below. In addition, you can also add bucket policy or through API or SDK. JSON policy example
The following policy example describes: granting all operations on objects in the folder/sub-folder directory of the Beijing region's bucket examplebucket-bj to the sub-account ID 100000000011 under the root account ID 100000000001 (APPID 1250000000).
{
"statement": [
{
"principal": {
"qcs": [
"qcs::cam::uin/100000000001:uin/100000000011"
]
},
"effect": "allow",
"action": [
"name/cos:*"
],
"resource": [
"qcs::cos:ap-beijing:uid/1250000000:examplebucket-bj-1250000000/folder/sub-folder/*"
]
}
],
"version": "2.0"
}
Operation Methods
COS allows you to add bucket policies by using the COS console, APIs, or SDKs. The COS console provides the Visual Editor configuration mode and common authorization templates to help users that are unfamiliar with the policy language to quickly add policies.
|
|
| Web page, intuitive and easy to use |
|
| RESTful API, sending requests directly to COS |
SDK | | Various SDK demos, supporting various development languages. |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
More Bucket Policy Examples
Note:
When adding a bucket policy, please ensure that you grant permissions according to your business needs and follow the principle of least privilege. If you directly grant other users access to all resources (resource:*) or all operations (action:*), there is a risk of data security due to excessively broad permissions.
The following are examples of bucket policies used to limit subnets, principals, or VPC IDs.
Example 1
Deny anonymous user (qcs::cam::anyone:anyone) request from subnet 10.1.1.0/24 and vpcid aqp5jrc1. Syntax example as follows.
Notes:
This denial policy takes effect only against anonymous users. If you need to limit CAM users (sub-account, root account), explicitly specify the account's Arn in the principal field.
{
"statement": [
{
"action": [
"name/cos:*"
],
"condition": {
"ip_equal": {
"qcs:ip": [
"10.1.1.0/24"
]
},
"string_equal": {
"vpc:requester_vpc": [
"vpc-aqp5jrc1"
]
}
},
"effect": "deny",
"principal": {
"qcs": [
"qcs::cam::anyone:anyone"
]
},
"resource": [
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
]
}
],
"version": "2.0"
}
Sample 2
Allow sub-account (qcs::cam::uin/100000000001:uin/100000000002) to access the specified bucket when the origin vpcid is aqp5jrc1. Syntax example as follows:
{
"statement": [
{
"action": [
"name/cos:*"
],
"condition": {
"string_equal": {
"vpc:requester_vpc": [
"vpc-aqp5jrc1"
]
}
},
"effect": "allow",
"principal": {
"qcs": [
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"resource": [
"qcs::cos:ap-beijing:uid/1250000000:examplebucket-1250000000/*"
]
}
],
"version": "2.0"
}