Configure and use bucket policies for access control - Object Storage Service

A Bucket Policy is a resource-based authorization policy attached to a bucket. You can use it to grant other Alibaba Cloud accounts, RAM users, or anonymous users access to your bucket, which enables scenarios such as cross-account authorization, anonymous access control, and restrictions based on IP addresses or VPCs.

How it works

A Bucket Policy is attached directly to a bucket and defines which Principals can perform which Actions on which Resources under which Conditions.

When a user sends an access request, OSS evaluates all relevant policies, including the Bucket Policy and any applicable RAM policies. The evaluation process follows one rule: explicit deny takes precedence. Any explicit Deny rule immediately blocks the request, overriding all Allow policies. If no Deny or Allow rule applies, the request is denied by default.

A Bucket Policy has special evaluation rules for the bucket owner:

When the Principal is set to a wildcard character (*) and the policy does not include a Condition element, the policy applies to all users except the bucket owner.
When the Principal is set to a wildcard character (*) and the policy includes a Condition element, the policy applies to all users, including the bucket owner.

If you configure multiple Bucket Policy rules for the same user, the user's permissions are the sum of all applicable rules. The principle that an explicit deny takes precedence still applies.

Important

When you configure a Bucket Policy, if you configure acs:SourceIp, you must also configure acs:SourceVpc.

Configure a bucket policy

OSS provides two methods for configuring a Bucket Policy: a graphical user interface (GUI) and a syntax-based policy editor. Each serves different needs.

Graphical user interface (GUI): Provides an intuitive, form-based experience for common authorization scenarios, simplifying configuration.
Syntax-based policy: Uses a JSON editor to write complete policies. This method supports all advanced features and complex condition combinations, offering maximum flexibility.

Graphical interface

Go to the Buckets page and click the name of the target bucket.
In the left-side navigation pane, choose Permission Control > Bucket Policy.

Select Add in GUI, and then click Authorize to open the policy configuration panel.

Parameter	Description
Applied To	Select whether the policy applies to the Whole Bucket or to Specific Resources.
Resource Paths	When Applied To is set to Whole Bucket, the Resource Paths is `bucket-name/`. If you set Applied To* to Specific Resources, enter the directory or object that you want to authorize. You can add multiple entries.
Authorized User	Specify the principal. *All Accounts (): The policy applies to anyone, including anonymous users. RAM user: Select a RAM user that belongs to the current Alibaba Cloud account. The current account must be a root account or a RAM user with management permissions for this bucket and the `ListUsers` permission in the RAM console. Otherwise, you cannot view the list of RAM users. Other accounts: Enter the UIDs of other accounts or RAM users, or the ARNs of assumed role users that start with `arn:sts`, such as `arn:sts::1798**********:assumed-role/role-name/session-name`. You can authorize multiple users. Enter one per line. If the authorized principal is a RAM role, they must access the resources programmatically by using tools such as ossutil, an SDK, or an API.
Authorized Operation	Simple Settings: Select a common combination of operations. Options include Read-Only (excluding ListObject), Read-Only (including ListObject), Read/Write, Full Access, and Deny Access. Important To ensure that the OSS-HDFS service can access the `.dlsdata/` directory and any objects in it, do not set a Deny Access action when you configure a Bucket Policy for a bucket that has the OSS-HDFS service enabled. If you must restrict access to specific network IP addresses or VPCs for security reasons, you need to add a special configuration. For more information, see Prerequisites for using OSS-HDFS. Advanced Settings: Customize the Effect (Allow or Reject) and the authorized Operation.
Condition (Optional)	Set the conditions under which the policy takes effect. Access Method: Options include HTTPS and HTTP. If selected, the policy takes effect only for requests that use the specified protocol. IP =: Enter a list of IP addresses. If selected, the policy takes effect only for requests from the specified IP addresses. IP ≠: Enter a list of IP addresses. If selected, the policy takes effect only for requests that do not originate from the specified IP addresses. VPC =: Select a VPC from the current account or enter the ID of a VPC from another account. If selected, the policy takes effect only for requests from the specified VPC. VPC ≠: Select a VPC from the current account or enter the ID of a VPC from another account. If selected, the policy takes effect only for requests that do not originate from the specified VPC. When you configure multiple conditions, all conditions must be met (AND logic) for the policy to take effect.

After you verify the settings, click OK.

Policy syntax

Go to the Buckets page and click the name of the target bucket.
In the left-side navigation pane, choose Permission Control > Bucket Policy.

Select Add by Syntax, and then click Edit. In the policy editor, enter a JSON-formatted policy.

Example authorization policy: For user 20214760404935xxxx, if an access request is not from the VPC network vpc-t4nlw426y44rd3iq4xxxx, then deny all actions on example-bucket.

{
    "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 policy includes a Version element and a Statement block.

Version: The version of the permission policy. The value is set to 1 and cannot be modified.

Statement: The main element of a policy. It contains one or more rules. Each rule is a statement that includes elements such as Effect, Action, Principal, Resource, and Condition.

Element	Description	Example
Effect	The effect of the policy. The value can be `Allow` or `Deny`.	Deny the request.
Action	The specific action to perform on the resource. The wildcard character `*` is supported.	Deny all OSS actions (`oss:*`).
Principal	The user, account, or role to which the policy applies. When the Principal field is set to an empty list (that is, `Principal:[]`), the behavior is identical to setting it to all accounts (that is, `Principal:["*"]`).	The policy applies only to the RAM user `20214760404935xxxx`.
Resource	The scope of resources to which the policy applies.	The policy applies to `example-bucket` itself and all objects within it.
Condition	The conditions under which the policy takes effect. When you configure multiple conditions, all conditions must be met (AND logic) for the policy to take effect.	This Deny policy takes effect only when the source VPC is not equal to `vpc-t4nlw426y44rd3iq4xxxx`.

For a complete list of policy elements, see Policy elements and syntax.

After verifying that the policy is correct, click Save and follow the on-screen instructions to save the policy.

Configure a vector bucket policy

For a vector bucket, you can configure a Bucket Policy only by using the syntax-based policy editor.

Go to the Vector Buckets page and click the name of the target vector bucket.
In the left-side navigation pane, choose Permission Control > Bucket Policy.

Click Edit. In the policy editor, enter a JSON-formatted policy.

Example authorization policy: Grant user 20816353761158**** the permission to read and write vector data on the index table indextest in vector-bucket-example.

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

A complete policy includes a Version element and a Statement block.

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

Element	Description	Example
Effect	The effect of the policy can be `Allow` or `Deny`.	Allow the request.
Action	The specific action to perform on the resource. The wildcard character `*` is supported.	Read and write vector data.
Principal	The user, account, or role to which the policy applies. When the Principal field is set to an empty list (that is, `Principal:[]`), its behavior is identical to setting it to all accounts (that is, `Principal:["*"]`).	The policy applies only to the RAM user `20816353761158****`.
Resource	The scope of resources to which the policy applies.	The policy applies to the index table `indextest` in `vector-bucket-example`.
Condition	The conditions under which the policy takes effect. When you configure multiple conditions, all conditions must be met (AND logic) for the policy to take effect.	None.

For a complete list of policy elements, see Policy elements and syntax.

After verifying that the policy is correct, click Save and follow the on-screen instructions to save the policy.

Use cases

The following scenarios show typical applications of a Bucket Policy, covering permission grants, access restrictions, and security controls. Each scenario provides a complete policy example that you can adapt to your needs.

Scenario 1: Grant read/write permissions to RAM users

When you need to allow specified members of your team 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 grants read and write permissions on the target bucket (example-bucket) to the RAM users with the UIDs 27737962156157xxxx and 20214760404935xxxx.

Note

Because this policy does not grant the oss:ListBuckets permission, the specified RAM users cannot view the bucket on the Buckets page. To access the bucket, the RAM users can add the bucket path to My Favorite Paths > + in the left-side navigation pane 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 permissions on a directory

If you want to protect specific project files in a bucket from being modified but allow project members to read them, you can grant read-only permissions to the corresponding RAM user. For example, you can grant a RAM user with the UID 20214760404935xxxx read-only permissions to directories that have the prefixes hangzhou/2020 and shanghai/2015 in the example-bucket bucket.

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 permissions to view a bucket and list objects

If you need to allow specific members of your team or partners to view all information about a bucket and list the files in it, you can use a Bucket Policy to grant the required permissions to the corresponding RAM user. The following example grants a specific RAM user the permissions to view all information about the target bucket (example-bucket) and list the files in 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 RAM role permissions to read objects

If you need to allow a RAM user or an application to temporarily access files in a bucket, you can create a RAM role and grant the required permissions. By assuming the role, the RAM user or application obtains temporary access credentials to read the files in the bucket. The following example grants the permission to read all files in the example-bucket bucket to all sessions of one RAM role and a specific session of another RAM role under an Alibaba Cloud account.

Note

When you grant permissions to a RAM role, the Principal must use the following format: arn:sts::<uid>:assumed-role/<role-name>/<session-name>. In this format, the <role-name> and <session-name> values 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 users permissions to list objects

When a bucket is used for public resource sharing and you want to allow all visitors to view filenames but not access the actual file content, you can set the Principal to the wildcard character (*) and grant the permission to list all files. The following example grants all visitors the 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: Block access from the internet

When you need to deny access to a specific bucket from the public internet, you can use the acs:SourceVpc condition key to create a Deny policy statement and add it to the Bucket Policy to block requests that do not originate from a VPC. Requests from the public internet are denied because they do not match the specified VPC network prefix. The following example denies access to the target bucket (example-bucket) for all requests that do not originate from a VPC.

{
  "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: Allow access only from a specific VPC

To restrict access to a bucket to a specific VPC, you can add a Deny policy statement with the acs:SourceVpc condition key to the Bucket Policy. This denies requests from other VPCs or the public internet because the requests do not originate from the specified VPC ID. The following example denies all requesters from reading files in the target bucket example-bucket unless the request originates from the specified VPC with the ID t4nlw426y44rd3iq4xxxx.

Note

Because the Principal in the following deny policy statement is the wildcard character asterisk (*) and the statement includes a Condition, the deny policy statement applies to all accessors, including the bucket owner.
The following Deny statement only restricts access and does not grant any permissions. If a principal has not been granted access permissions, you must also add an Allow statement to grant the required permissions.
If the OSS-HDFS service is enabled for the bucket, you must add the following condition to all Deny statements. This ensures that the OSS-HDFS backend service can read and write to the bucket over the classic network:
```
"StringNotLike": {
    "oss:ClassicIntranet": [
        "true"
    ]
}
```

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

Scenario 8: Allow access only from a specific public IP address

To restrict access to a bucket to a specific public IP address, create a Deny policy statement that uses the acs:SourceIp condition key and add it to the Bucket Policy. This policy blocks requests from other public IP addresses. Requests from other public IP addresses do not meet the specified IP condition and therefore trigger the deny rule. The following example denies read operations on example-bucket for all visitors except those from the public IP address 203.0.113.5.

Note

Because the Principal in the following deny policy statement is the wildcard character asterisk (*) and the statement includes a Condition, the deny policy statement applies to all accessors, including the bucket owner.
The following Deny statement only restricts access and does not grant any permissions. If a principal has not been granted access permissions, you must also add an Allow statement to grant the required permissions.
If the OSS-HDFS service is enabled for the bucket, you must add the following condition to all Deny statements. This ensures that the OSS-HDFS backend service can read and write to the bucket over the classic network:
```
"StringNotLike": {
    "oss:ClassicIntranet": [
        "true"
    ]
}
```

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

Scenario 9: Allow access from a specific IP range in a VPC

To restrict bucket access to a specific IP address range within a specific VPC, you must create two Deny statements:

Use theacs:SourceVpc condition key to create a deny policy statement that blocks requests from other VPCs or the public internet. Requests from other public IP addresses or VPCs are identified as not meeting the specified IP condition, which triggers the deny rule.
Use the acs:SourceIp and acs:SourceVpc condition keys to create a deny policy statement that blocks requests from outside a specified VPC network segment.

After you add the two preceding Deny statements to a Bucket Policy, access is denied if either condition is met. The following example denies all requests to read objects from the target bucket (example-bucket) except for requests that originate from the 192.168.0.0/16 IP address range in the specified VPC (ID: t4nlw426y44rd3iq4xxxx).

Note

Because the Principal in the following deny policy statement is the wildcard character asterisk (*) and the statement includes a Condition, the deny policy statement applies to all accessors, including the bucket owner.
The following Deny statement only restricts access and does not grant any permissions. If a principal has not been granted access permissions, you must also add an Allow statement to grant the required permissions.
If the OSS-HDFS service is enabled for the bucket, you must add the following condition to all Deny statements. This ensures that the OSS-HDFS backend service can read and write to the bucket over the classic network:
```
"StringNotLike": {
    "oss:ClassicIntranet": [
        "true"
    ]
}
```

{
    "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: Allow access from a specific IP or VPC

To restrict bucket access to a specific public IP address or a specific VPC, you must create two Deny statements:

Create a deny policy statement that uses the acs:SourceIp condition key to block requests from other public IP addresses, and the StringNotLike condition operator and the acs:SourceVpc condition key to exclude requests from a specified VPC.
Use the acs:SourceVpc condition key to create a deny policy statement that blocks requests from other VPCs. At the same time, use the StringLike condition operator with the acs:SourceVpc key to exclude requests from specified public IP addresses. This prevents these requests from being incorrectly denied for failing to meet the VPC ID condition.

After the two preceding deny policy statements are added to a Bucket Policy, a request is denied if either condition is met. The following example denies all visitors, except for those from the specified public IP address 203.0.113.5 or the specified VPC t4nlw426y44rd3iq4xxxx, from reading files in the target bucket example-bucket.

Note

Because the Principal in the following deny policy statement is the wildcard character asterisk (*) and the statement includes a Condition, the deny policy statement applies to all accessors, including the bucket owner.
The following Deny statement only restricts access and does not grant any permissions. If a principal has not been granted access permissions, you must also add an Allow statement to grant the required permissions.
If the OSS-HDFS service is enabled for the bucket, you must add the following condition to all Deny statements. This ensures that the OSS-HDFS backend service can read and write to the bucket over the classic network:
```
"StringNotLike": {
    "oss:ClassicIntranet": [
        "true"
    ]
}
```

{
    "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: Configure an IP blacklist

To deny access to a bucket and its objects from specific IP addresses, you can use an IP blacklist policy. By configuring a Deny policy in the Bucket Policy, you can block all access requests from specified IP addresses or IP address ranges.

Note

Because the Principal in the following deny policy statement is the wildcard character asterisk (*) and the statement includes a Condition, the deny policy statement applies to all accessors, including the bucket owner.
You can configure multiple IP addresses and IP address ranges. 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"
        ]
      },
      "StringLike": {
        "acs:SourceVpc": [
          "*"
        ]
      }
    }
  }]
}

Scenario 12: Require temporary credentials for API calls

When you access bucket resources through an API, you can enforce the use of temporary access credentials. To do this, add a Deny policy statement that uses the acs:AccessId condition key to your Bucket Policy. This statement blocks access from other non-temporary credentials, such as the long-term access keys of an Alibaba Cloud account or a RAM user. Access attempts made with non-temporary credentials trigger the Deny rule in the policy. The following example denies all visitors, except for those who use temporary access credentials that start with TMP. or STS., from viewing the target bucket (example-bucket) and listing 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 public ACLs for buckets and objects

To prohibit setting bucket and object ACLs to allow public access, you can create two Deny statements:

Use the oss:x-oss-acl condition key to create a Deny policy statement that prevents the Bucket ACL from being set to any permission other than private. Any attempt to set the permission to public-read or public-read-write is identified as a violation of the private condition and triggers the deny rule.
Use the oss:x-oss-object-acl condition key to create a deny policy statement to prevent the Object ACL from being set to any permission other than private or default.

After adding the two deny policy statements above to the Bucket Policy, a deny action is triggered if either condition is met. The following example 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

Besides using the console, you can manage Bucket Policy authorization with graphical tools, command-line tools, and SDKs.

Use the graphical tool ossbrowser
ossbrowser provides a visual interface, similar to that of the console, for managing bucket policies. After you install and log on to ossbrowser, follow the on-screen instructions to configure the Bucket Policy.
Use the command-line tool ossutil
Set an authorization policy by running the put-bucket-policy command.
Note
To set an authorization policy for a vector bucket, run the ossutil vectors-api put-bucket-policy command.
Use an SDK
You can configure policies by using SDKs for 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
Call the PutBucketPolicy operation to set an authorization policy for a bucket.

Quotas and Limits

Policy size: A bucket can have only one Bucket Policy. This policy can contain multiple rules, but its total size cannot exceed 16 KB.
Field length: The length of each field in a Bucket Policy cannot exceed 4,095 bytes.

Object Storage Service:Bucket Policy

How it works

Configure a bucket policy

Graphical interface

Policy syntax

Configure a vector bucket policy

Use cases

Scenario 1: Grant read/write permissions to RAM users

Scenario 2: Grant read-only permissions on a directory

Scenario 3: Grant permissions to view a bucket and list objects

Scenario 4: Grant a RAM role permissions to read objects

Scenario 5: Grant all users permissions to list objects

Scenario 6: Block access from the internet

Scenario 7: Allow access only from a specific VPC

Scenario 8: Allow access only from a specific public IP address

Scenario 9: Allow access from a specific IP range in a VPC

Scenario 10: Allow access from a specific IP or VPC

Scenario 11: Configure an IP blacklist

Scenario 12: Require temporary credentials for API calls

Scenario 13: Prohibit public ACLs for buckets and objects

Development and tool integration

Quotas and Limits

References