Set an authorization policy by using a bucket policy - Object Storage Service

A bucket policy is a resource-based access control policy attached to a bucket. It uses the JSON format to define granular access rules that specify the operations (Action) a principal (Principal) can perform on a target resource (Resource) when specific conditions (Condition) are met. As a core mechanism for complex access restrictions, such as cross-account authorization, anonymous access control, and limits based on the network source, a bucket policy provides fine-grained permission management.

How it works

A bucket policy uses a resource-based authorization model. Permission evaluation follows the deny-first principle. When Object Storage Service (OSS) receives an access request, the system evaluates all relevant policies, including bucket policies and Resource Access Management (RAM) policies. An explicit deny rule in any policy immediately blocks the request and takes precedence over any allow policies.

How policies affect the bucket owner:
- If the authorized user is set to a wildcard character (*) and the policy does not include a Condition, the bucket policy applies only to users other than the bucket owner.
- If the authorized user is set to a wildcard character (*) and the policy includes a Condition, the bucket policy applies to all users, including the bucket owner (root account).
Combining multiple bucket policy rules:
When you configure multiple bucket policy rules for the same user, the user's permissions are the combination of all policy rules. If any of these policies include a deny permission, the deny permission takes precedence.

Configure a bucket authorization policy

OSS provides two ways to configure policies: a graphical interface and a syntax editor. These methods are suitable for different configuration scenarios.

Graphical interface: This method provides an intuitive experience. You can use a form to configure policies for common authorization scenarios, which simplifies the process.
Syntax editor: This method uses the JSON format to write complete policies. It supports all advanced features and complex condition combinations, providing maximum configuration flexibility.

Graphical policy method

Go to the Buckets list and click the target bucket.
In the navigation pane on the left, click Permission Control > Bucket Policy.

Select Add in GUI, and then click Authorize.

Configuration Item	Description
Applied To	Select whether to authorize the Whole Bucket or Specific Resources.
Resource Paths	If you set Applied To to Whole Bucket, the Resource Paths is `bucket-name/`. If you set Applied To* to Specific Resources, enter the folder or individual object of the resource to authorize. You can add multiple records.
Authorized User	Specify the authorized object. *All Accounts (): The authorized object is anyone, including anonymous visitors. RAM User: Select a RAM user under the current Alibaba Cloud account. The current logon account must be an Alibaba Cloud account or a RAM user with management permissions for this bucket and the `ListUsers` permission in the RAM console. Otherwise, you cannot view the RAM user list for the current account. Other Accounts: Enter the UIDs of other accounts or RAM users to authorize, or temporary authorized users starting with `arn:sts`, such as `arn:sts::1798**********:assumed-role/role-name/session-name`. You can authorize multiple users. Enter one user per line. When the authorized object is a RAM role, the account cannot access the authorized resources through the OSS console. Access must be made using tools such as the ossutil command line interface, a software development kit (SDK), or an API.
Authorized Operation	Simple Settings: Select a common combination of authorized operations. Options include Read-Only (excluding ListObject), Read-Only (including ListObject), Read/Write, Full Access, and Deny Access. Note To ensure that OSS-HDFS service users can access the `.dlsdata/` folder and any objects within it, do not set the authorized operation to Deny Access when you configure a bucket policy for a bucket with OSS-HDFS enabled. Advanced Settings: Customize the authorization Effect (Allow or Reject) and the authorized Operation.
Condition (Optional)	Set the conditions for the authorization to take effect. Access Method: Options include HTTPS and HTTP. If you select an option, the policy takes effect only for access requests that use the selected method. IP =: Enter a list of IP addresses. If you select this option, the policy takes effect only for access requests from the specified IP addresses. IP ≠: Enter a list of IP addresses. If you select this option, the policy takes effect only for access requests that are not from the specified IP addresses. VPC =: Select a VPC of the current account or enter a VPC of another account. If you select this option, the policy takes effect only for access requests from the specified VPC. VPC ≠: Select a VPC of the current account or enter a VPC of another account. If you select this option, the policy takes effect only for access requests that are not from the specified VPC. When you configure multiple conditions, all conditions must be met (an AND relationship) for the policy to take effect.

After you confirm the authorization configuration, click OK to apply the bucket policy.

Syntax-based policy approach

Go to the Buckets list and click the target bucket.
In the navigation pane on the left, click Permission Control > Bucket Policy.

Select Add by Syntax, and then click Edit. In the editor, enter the authorization policy in JSON format.

Example policy: This example policy denies all operations on example-bucket for the user 20214760404935xxxx if an access request does not originate from the VPC network vpc-t4nlw426y44rd3iq4xxxx.

{
    "Version": "1",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "oss:*",
            "Principal": [
                "20214760404935xxxx"
            ],
            "Resource": [
                "acs:oss:*:174649585760xxxx:example-bucket",
                "acs:oss:*:174649585760xxxx:example-bucket/*"
            ],
            "Condition": {
                "StringNotEquals": {
                    "acs:SourceVpc": "vpc-t4nlw426y44rd3iq4xxxx"
                }
            }
        }
    ]
}

A complete authorization policy includes a Version and a Statement.

Version: The version of the access policy. The value is fixed at 1 and cannot be changed.

Statement: The main body of the policy statement. It contains one or more specific authorization or denial rules. Each authorization statement includes an Effect, an Action, a Principal, a Resource, and a Condition.

Policy Element	Description	Meaning in the example policy
Effect	The effect of the policy. Valid values are `Allow` and `Deny`.	Deny the request.
Action	The specific operation to perform on the resource. The wildcard character `*` is supported.	Deny all OSS operations (`oss:*`).
Principal	The entity that the policy applies to, such as a user, account, or role. If the Principal field is configured as an empty list (`Principal:[]`), its behavior is identical to being configured for all accounts (`Principal:["*"]`).	The policy applies only to the RAM user `20214760404935xxxx`.
Resource	The scope of the resources that the policy applies to.	The policy applies to `example-bucket` itself and all objects within it.
Condition	The conditions for the policy to take effect. When you configure multiple conditions, all conditions must be met (an AND relationship) for the policy to take effect.	This Deny policy takes effect only when the source VPC of the request is not `vpc-t4nlw426y44rd3iq4xxxx`.

For a complete list of authorization elements, see OSS authorization syntax and elements.

After you confirm the authorization policy, click Save and follow the on-screen instructions.

Configure an authorization policy for a vector bucket

Vector buckets currently support configuring bucket policies only using the syntax editor.

Go to the Vector Buckets list and click the target vector bucket.
In the navigation pane on the left, click Permission Control > Bucket Policy.

Click Edit. In the editor, enter the authorization policy in JSON format.

Example policy: This example policy grants user 20816353761158**** permissions to read and write vector data in the index table indextest within vector-bucket-example.

{
  "Version": "1",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "oss:PutVectors",
      "oss:GetVectors"
    ],
    "Principal": [
      "20816353761158****"
    ],
    "Resource": [
      "acs:ossvector:*:*:vector-bucket-example/indextest"
    ]
  }]
}

A complete authorization policy includes a Version and a Statement.

Version: The version of the access policy. The value is fixed at 1 and cannot be changed.

Policy Element	Description	Meaning in the example policy
Effect	The effect of the policy. Valid values are `Allow` and `Deny`.	Allow the request.
Action	The specific operation to perform on the resource. The wildcard character `*` is supported.	Read and write vector data.
Principal	The entity that the policy applies to, such as a user, account, or role. If the Principal field is configured as an empty list (`Principal:[]`), its behavior is identical to being configured for all accounts (`Principal:["*"]`).	The policy applies only to the RAM user `20816353761158****`.
Resource	The scope of the resources that the policy applies to.	The policy applies to the index table `indextest` in `vector-bucket-example`.
Condition	The conditions for the policy to take effect. When you configure multiple conditions, all conditions must be met (an AND relationship) for the policy to take effect.	None.

For a complete list of authorization elements, see OSS authorization syntax and elements.

After you confirm the authorization policy, click Save and follow the on-screen instructions.

Common authorization scenarios

The following scenarios show typical applications of bucket policies in real-world business. These scenarios cover various needs, such as permission granting, access restriction, and security control. Each scenario provides a complete policy configuration example that you can modify based on your requirements.

Scenario 1: Grant read/write permissions to a specified RAM user

When you need to allow specific team members or partners to upload, download, and manage files in a bucket, you can use a bucket policy to grant permissions to the corresponding RAM users. The following example policy grants read/write permissions for the target bucket (example-bucket) to specified RAM users (UIDs 27737962156157xxxx and 20214760404935xxxx).

Note

Because the following policy does not grant the RAM users permission to list buckets, the specified RAM users cannot view all buckets on the Buckets list page or click a bucket to open it. The specified RAM users can access the target bucket by adding it from My Favorite Paths > + in the navigation pane on the left of the console.

{
    "Version":"1",
    "Statement":[
        {
            "Effect":"Allow",
            "Action":[
                "oss:GetObject",
                "oss:PutObject",
                "oss:GetObjectAcl",
                "oss:PutObjectAcl",
                "oss:AbortMultipartUpload",
                "oss:ListParts",
                "oss:RestoreObject",
                "oss:GetVodPlaylist",
                "oss:PostVodPlaylist",
                "oss:PublishRtmpStream",
                "oss:ListObjectVersions",
                "oss:GetObjectVersion",
                "oss:GetObjectVersionAcl",
                "oss:RestoreObjectVersion"
            ],
            "Principal":[
                "27737962156157xxxx",
                "20214760404935xxxx"
            ],
            "Resource":[
                "acs:oss:*:174649585760xxxx:example-bucket/*"
            ]
        },
        {
            "Effect":"Allow",
            "Action":[
                "oss:ListObjects"
            ],
            "Principal":[
                "27737962156157xxxx",
                "20214760404935xxxx"
            ],
            "Resource":[
                "acs:oss:*:174649585760xxxx:example-bucket"
            ],
            "Condition":{
                "StringLike":{
                    "oss:Prefix":[
                        "*"
                    ]
                }
            }
        }
    ]
}

Scenario 2: Grant read-only permission for a specified folder to a specified RAM user

When you need to protect specific project files in a bucket from being modified but allow relevant project members to read them, you can grant read-only permission to the corresponding RAM users. The following example policy grants read-only permission for specified folders (with prefixes hangzhou/2020 and shanghai/2015) in the target bucket (example-bucket) to a specified RAM user (UID 20214760404935xxxx).

Note

{
    "Version":"1",
    "Statement":[
        {
            "Action":[
                "oss:GetObject",
                "oss:GetObjectAcl",
                "oss:GetObjectVersion",
                "oss:GetObjectVersionAcl"
            ],
            "Effect":"Allow",
            "Principal":[
                "20214760404935xxxx"
            ],
            "Resource":[
                "acs:oss:*:174649585760xxxx:example-bucket/hangzhou/2020/*",
                "acs:oss:*:174649585760xxxx:example-bucket/shanghai/2015/*"
            ]
        },
        {
            "Action":[
                "oss:ListObjects",
                "oss:ListObjectVersions"
            ],
            "Condition":{
                "StringLike":{
                    "oss:Prefix":[
                        "hangzhou/2020/*",
                        "shanghai/2015/*"
                    ]
                }
            },
            "Effect":"Allow",
            "Principal":[
                "20214760404935xxxx"
            ],
            "Resource":[
                "acs:oss:*:174649585760xxxx:example-bucket"
            ]
        }
    ]
}

Scenario 3: Grant a specified RAM user permission to view a bucket and list its files

When you need to allow specific team members or partners to view all information about a bucket and list its files, you can use a bucket policy to grant the corresponding permissions to the RAM users. The following example policy grants a specified RAM user permission to view all information about the target bucket (example-bucket) and list the files within it.

Note

{
    "Version":"1",
    "Statement":[
        {
            "Action":[
                "oss:Get*",
                "oss:ListObjects",
                "oss:ListObjectVersions"
            ],
            "Effect":"Allow",
            "Principal":[
                "20214760404935xxxx"
            ],
            "Resource":[
                "acs:oss:*:174649585760xxxx:example-bucket"
            ]
        }
    ]
}

Scenario 4: Grant a specified RAM role permission to read files

When you need to allow RAM users or applications to temporarily access bucket files, you can create a RAM role and grant it the necessary permissions. The RAM user or application assumes the role to obtain temporary access credentials to read the bucket files. The following example policy grants all sessions under one RAM role and a specific session under another RAM role permission to read all files in the bucket example-bucket.

Note

When you grant permissions to a RAM role, the Principal must follow this format: arn:sts::<uid>:assumed-role/<role-name>/<session-name>. The values for <role-name> and <session-name> are case-sensitive.

{
    "Version": "1",
    "Statement": [
        {
            "Action": [
                "oss:GetObject"
            ],
            "Effect": "Allow",
            "Principal": [
                "arn:sts::10323xxxxx72056:assumed-role/role-name/session-name",
                "arn:sts::10323xxxxx72056:assumed-role/role2-name/*"
            ],
            "Resource": [
                "acs:oss:*:10323xxxxx72056:example-bucket/*"
            ]
        }
    ]
}

Scenario 5: Grant all visitors permission to list all files

When a bucket is used for sharing public resources and you need to allow all visitors to view filenames but not access the actual file content, you can set the Principal to a wildcard character (*) and grant it permission to list all files. The following example policy grants all visitors permission to list all files in the target bucket (example-bucket).

{
    "Version":"1",
    "Statement":[
        {
            "Action":[
                "oss:ListObjects",
                "oss:ListObjectVersions"
            ],
            "Effect":"Allow",
            "Principal":[
                "*"
            ],
            "Resource":[
                "acs:oss:*:174649585760xxxx:example-bucket"
            ]
        }
    ]
}

Scenario 6: Restrict access from the public network

When you need to prohibit access to a specific bucket from the public network, you can use the acs:SourceVpc condition key to create a deny statement in the bucket policy. This statement blocks requests that do not originate from a VPC because public network requests do not have a matching VPC network prefix. The following example policy denies access to the target bucket (example-bucket) for all visitors outside a VPC network.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "oss:*",
      "Principal": [
        "*"
      ],
      "Resource": [
        "acs:oss:*:174649585760xxxx:example-bucket/*",
        "acs:oss:*:174649585760xxxx:example-bucket"
      ],
      "Condition": {
        "StringNotLike": {
          "acs:SourceVpc": [
            "vpc-*"
          ]
        }
      }
    }
  ]
}

Scenario 7: Restrict access to a specified VPC

When you need to restrict access to a bucket to a specified VPC, you can use the acs:SourceVpc condition key to create a deny statement in the bucket policy. This statement blocks requests that originate from other VPCs or the public network because they do not meet the specified VPC ID condition. The following example policy denies all visitors outside the specified VPC (ID t4nlw426y44rd3iq4xxxx) permission to read files in the target bucket (example-bucket).

Note

Because the Principal in the following deny statement is a wildcard character (*) and includes a Condition, the deny statement applies to all visitors, including the bucket owner.
The following deny statement is only used to restrict access and does not grant any access permissions. If the authorized entity has not been granted access permissions, you must also add an allow statement to grant the required permissions.

{
    "Version":"1",
    "Statement":[
        {
            "Effect":"Deny",
            "Action":[
                "oss:GetObject"
            ],
            "Principal":[
                "*"
            ],
            "Resource":[
                "acs:oss:*:174649585760xxxx:example-bucket/*"
            ],
            "Condition":{
                "StringNotEquals":{
                    "acs:SourceVpc":[
                        "vpc-t4nlw426y44rd3iq4xxxx"
                    ]
                }
            }
        }
    ]
}

Scenario 8: Restrict access to a specified public IP address

When you need to restrict access to a bucket to a specified public IP address, use the acs:SourceIp condition key to create a deny statement in the bucket policy. This statement blocks requests from other public IP addresses or VPCs because they do not meet the specified IP address condition. The following example policy denies all visitors except those from the public IP address 203.0.113.5 permission to read from example-bucket.

Note

Because the Principal in the following deny statement is a wildcard character (*) and includes a Condition, the deny statement applies to all visitors, including the bucket owner.
The following deny statement is only used to restrict access and does not grant any access permissions. If the authorized entity has not been granted access permissions, you must also add an allow statement to grant the required permissions.

{
    "Version":"1",
    "Statement":[
        {
            "Effect":"Deny",
            "Action":[
                "oss:GetObject"
            ],
            "Principal":[
                "*"
            ],
            "Resource":[
                "acs:oss:*:174649585760xxxx:example-bucket/*"
            ],
            "Condition":{
                "NotIpAddress":{
                    "acs:SourceIp":[
                        "203.0.113.5"
                    ]
                }
            }
        }
    ]
}

Scenario 9: Restrict access to a specified CIDR block within a specified VPC

When you need to restrict access to a bucket to a specified CIDR block within a specified VPC, you must create two deny statements:

Use the acs:SourceVpc condition key to create a deny statement that blocks requests from other VPCs or the public network.
Use the acs:SourceIp and acs:SourceVpc condition keys to create a deny statement that blocks requests from outside the specified CIDR block within the VPC.

After you add these two deny statements to the bucket policy, a request is denied if it meets either condition. The following example policy denies all visitors outside the specified CIDR block (192.168.0.0/16) of the specified VPC (ID t4nlw426y44rd3iq4xxxx) permission to read files in the target bucket (example-bucket).

Note

Because the Principal in the following deny statement is a wildcard character (*) and includes a Condition, the deny statement applies to all visitors, including the bucket owner.
The following deny statement is only used to restrict access and does not grant any access permissions. If the authorized entity has not been granted access permissions, you must also add an allow statement to grant the required permissions.

{
    "Version":"1",
    "Statement":[
        {
            "Effect":"Deny",
            "Action":[
                "oss:GetObject"
            ],
            "Principal":[
                "*"
            ],
            "Resource":[
                "acs:oss:*:174649585760xxxx:example-bucket/*"
            ],
            "Condition":{
                "StringNotEquals":{
                    "acs:SourceVpc":[
                        "vpc-t4nlw426y44rd3iq4xxxx"
                    ]
                }
            }
        },
        {
            "Effect":"Deny",
            "Action":[
                "oss:GetObject"
            ],
            "Principal":[
                "*"
            ],
            "Resource":[
                "acs:oss:*:174649585760xxxx:example-bucket/*"
            ],
            "Condition":{
                "StringEquals":{
                    "acs:SourceVpc":[
                        "vpc-t4nlw426y44rd3iq4xxxx"
                    ]
                },
                "NotIpAddress":{
                    "acs:SourceIp":[
                        "192.168.0.0/16"
                    ]
                }
            }
        }
    ]
}

Scenario 10: Restrict access to a specified public IP address or a specified VPC

When you need to restrict access to a bucket to a specified public IP address or a specified VPC, you must create two deny statements:

A deny statement that uses the acs:SourceIp condition key to block requests from other public IP addresses. This statement also uses the StringNotLike condition operator with the acs:SourceVpc condition key to avoid blocking requests from any VPC.
You can use the acs:SourceVpc condition key to create a deny policy statement that blocks requests from other VPCs. In the same statement, use the StringLike condition operator and the acs:SourceVpc key to exclude requests from specified public IP addresses. This prevents requests from these public IP addresses from being incorrectly denied because they do not originate from the specified VPC.

After you add these two deny statements to the bucket policy, a request is denied if it meets either condition. The following example policy denies all visitors outside the specified public IP address (203.0.113.5) or the specified VPC (ID t4nlw426y44rd3iq4xxxx) permission to read files in the target bucket (example-bucket).

Note

Because the Principal in the following deny statement is a wildcard character (*) and includes a Condition, the deny statement applies to all visitors, including the bucket owner.
The following deny statement is only used to restrict access and does not grant any access permissions. If the authorized entity has not been granted access permissions, you must also add an allow statement to grant the required permissions.

{
    "Version":"1",
    "Statement":[
        {
            "Effect":"Deny",
            "Action":[
                "oss:GetObject"
            ],
            "Principal":[
                "*"
            ],
            "Resource":[
                "acs:oss:*:174649585760xxxx:example-bucket/*"
            ],
            "Condition":{
                "StringNotLike":{
                    "acs:SourceVpc":[
                        "vpc-*"
                    ]
                },
                "NotIpAddress":{
                    "acs:SourceIp":[
                        "203.0.113.5"
                    ]
                }
            }
        },
        {
            "Effect":"Deny",
            "Action":[
                "oss:GetObject"
            ],
            "Principal":[
                "*"
            ],
            "Resource":[
                "acs:oss:*:174649585760xxxx:example-bucket/*"
            ],
            "Condition":{
                "StringLike":{
                    "acs:SourceVpc":[
                        "vpc-*"
                    ]
                },
                "StringNotEquals":{
                    "acs:SourceVpc":[
                        "vpc-t4nlw426y44rd3iq4xxxx"
                    ]
                }
            }
        }
    ]
}

Scenario 11: Set an IP blacklist

When you need to deny access to a bucket and its objects from specific IP addresses, you can use an IP blacklist policy. By setting a deny policy in the bucket policy, you can block all access requests from specified IP addresses or CIDR blocks.

Note

Because the Principal in the following deny statement is a wildcard character (*) and includes a Condition, the deny statement applies to all visitors, including the bucket owner.
You can configure multiple IP addresses and CIDR blocks at the same time. Separate them with commas.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "oss:*",
      "Principal": [
        "*"
      ],
      "Resource": [
        "acs:oss:*:174649585760xxxx:example-bucket/*",
        "acs:oss:*:174649585760xxxx:example-bucket"
      ],
      "Condition": {
        "IpAddress": {
          "acs:SourceIp": [
            "101.***.***.100"
          ]
        }
      }
    }
  ]
}

Scenario 12: Require temporary access credentials for API calls

To require that API calls use temporary access credentials, you can use the acs:AccessId condition key to create a deny statement in the bucket policy. This statement blocks access methods that use non-temporary credentials, such as the long-term AccessKey pairs of an Alibaba Cloud account or a RAM user. Access attempts that use non-temporary credentials trigger the deny rule. The following example policy denies all visitors except those who use temporary access credentials (starting with TMP. or STS.) permission to view the target bucket (example-bucket) and list its files.

{
    "Version": "1",
    "Statement": [
        {            
            "Effect": "Deny",
            "Action":[
                "oss:Get*",
                "oss:ListObjects",
                "oss:ListObjectVersions"
            ],
            "Principal":[
                "*"
            ],
            "Resource":[
                "acs:oss:*:174649585760xxxx:example-bucket/*"
            ],
            "Condition": {
                "StringNotLike": {
                    "acs:AccessId": [
                        "TMP.*",
                        "STS.*"
                 ]
                }
            }
        }
    ]
}

Scenario 13: Prohibit setting bucket and object ACLs to public

When you need to prohibit setting bucket and object ACLs to public, you can create two deny statements:

Use the oss:x-oss-acl condition key to create a deny statement that prevents the bucket ACL from being set to any permission other than private. Any attempt to set public-read or public-read-write permissions triggers the deny rule because the permission is not private.
Use the oss:x-oss-object-acl condition key to create a deny statement that prevents the object ACL from being set to any permission other than private and default.

After you add these two deny statements to the bucket policy, a request is denied if it meets either condition. The following example policy denies operations that set public access permissions on the target bucket (example-bucket).

{
    "Version": "1",
    "Statement": [
        {            
            "Effect": "Deny",
            "Action": [
                "oss:PutBucketAcl"
            ],
            "Principal": [
                "*"
            ],
            "Resource": [
                "acs:oss:*:*:example-bucket"
            ],
            "Condition": {
                "StringNotEquals": {
                    "oss:x-oss-acl": "private"
                }
            }
        },
        {            
            "Effect": "Deny",
            "Action": [
                "oss:PutObjectAcl"
            ],
            "Principal": [
                "*"
            ],
            "Resource": [
                "acs:oss:*:*:example-bucket/*"
            ],
            "Condition": {
                "StringNotEquals": {
                    "oss:x-oss-object-acl": [
                        "private",
                        "default"
                    ]
                }
            }
        }
    ]
}

Development and tool integration

In addition to manual configuration in the console, you can also use graphical tools, command-line tools, and SDKs to configure a bucket policy.

Use the graphical tool ossbrowser
ossbrowser supports bucket-level policy operations and provides a visual experience similar to the console. Install and log on to ossbrowser, then follow the on-screen instructions to configure the bucket policy.
Use the command line interface ossutil
You can set the authorization policy by running the put-bucket-policy command.
Note
To set an authorization policy for a vector bucket, use the ossutil vectors-api put-bucket-policy command.
Use an SDK
You can configure policies using various programming languages, such as the Java SDK, Python SDK, Go SDK, and Node.js SDK. For more information about supported SDKs, see SDK Reference.
Call an API directly
You can call the PutBucketPolicy operation to set an authorization policy for a bucket.

Quotas and limits

Policy size: You can add multiple bucket policies to a single bucket. The total size of all policies cannot exceed 16 KB.
Field length: The length of each field in a bucket policy cannot exceed 4,095 bytes.

Object Storage Service:Set an authorization policy by using a bucket policy

How it works

Configure a bucket authorization policy

Graphical policy method

Syntax-based policy approach

Configure an authorization policy for a vector bucket

Common authorization scenarios

Scenario 1: Grant read/write permissions to a specified RAM user

Scenario 2: Grant read-only permission for a specified folder to a specified RAM user

Scenario 3: Grant a specified RAM user permission to view a bucket and list its files

Scenario 4: Grant a specified RAM role permission to read files

Scenario 5: Grant all visitors permission to list all files

Scenario 6: Restrict access from the public network

Scenario 7: Restrict access to a specified VPC

Scenario 8: Restrict access to a specified public IP address

Scenario 9: Restrict access to a specified CIDR block within a specified VPC

Scenario 10: Restrict access to a specified public IP address or a specified VPC

Scenario 11: Set an IP blacklist

Scenario 12: Require temporary access credentials for API calls

Scenario 13: Prohibit setting bucket and object ACLs to public

Development and tool integration

Quotas and limits

References