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.
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.
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:
A bucket policy is described in JSON language and its syntax complies with the unified specifications of the access policy language. The access policy language contains the following basic elements: principal, effect, action, resource, and condition. For more information, see Access Policy Language Overview.
The resource scope of a bucket policy is restricted to the bucket, and you can perform authorization on the entire bucket, specified directories, or specified objects.
Note:When adding an access policy, be sure to grant the minimum permissions needed to satisfy your business needs. There may be data security risks if you grant other users the permission to access all of your resources
(resource:*)
or all operations(action:*)
.
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:
Configuration Item | Description |
---|---|
Effect | Allow |
Principal | UIN of the sub-account, which must be a sub-account under the current root account, such as 100000000011 |
Resource | Specified directory prefix, such as folder/sub-folder/* |
Action | All operations |
Condition | None |
In the COS console, you can add and manage bucket policies in two modes: Visual Editor and JSON.
Click the target bucket and choose Permission Management > Permission Policy Settings > Visual Editor. On the Visual Editor tab page, click Add Policy. In the pop-up window, configure the policy in two steps:
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.
*
) will be automatically selected for you during policy configuration in step 2.A template is a collection of operations that you want to authorize. COS provides you with different recommended templates depending on the combination of authorized users and resource scope you choose. If the templates provided by COS do not meet your requirements, you can skip this step and add or delete authorized operations during policy configuration in step 2.
Templates are described in the following table.
Grantee | Resource Scope | Policy Template | Description |
---|---|---|---|
All combinations | Custom | 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) | COS provides the most recommended templates for the combination of Specified user and The whole bucket. In addition to reading, writing, and listing files, COS provides the following sensitive permission templates for trusted users: |
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:To authorize the permissions of a directory, you need to add
/*
to the resource path entered. For example, to authorize thetest
directory, you need to entertest/*
.
If the recommended templates provided by COS do not meet your requirements, you can add or delete authorized users, resources, and operations in this step.
The configuration items are described as follows:
allow
or deny
in the policy syntax.*
), Root account, Sub-account, and Cloud service.
If you are familiar with bucket policies, you can click the target bucket, choose Permission Management > Permission Policy Settings > JSON, and write the bucket policy in JSON language.
After writing the bucket policy, you can add it via API or SDK.
The following policy is to allow root account 100000000001 (APPID: 1250000000) to grant sub-account 100000000011 with all operation permissions of the objects in the folder/sub-folder
directory in the examplebucket-bj
bucket of the Beijing region.
{
"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"
}
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.
Operation Method | Description | |
---|---|---|
Console | Web page, intuitive and easy to use | |
API | RESTful API, sending requests directly to COS | |
SDK | JavaScript | Rich SDK demos, supporting various programming languages |
Node.js | ||
Mini Program |
Note:When adding an access policy, be sure to grant the minimum permissions needed to satisfy your business needs. There may be data security risks if you grant other users the permission to access all of your resources
(resource:*)
or all operations(action:*)
.
The following are examples of bucket policies used to limit subnets, principals and VPC IDs.
Limit the IP range in the subnet to 10.1.1.0/24 and the VPC ID to aqp5jrc1:
{
"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"
}
Limit the VPC ID to aqp5jrc1 and specify the principal and bucket:
{
"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"
}
Was this page helpful?