Configure a bucket policy-Object Storage Service(OSS)-阿里云帮助中心

How it works

A bucket policy uses a resource-based model: it attaches to a bucket and defines which principals can perform which actions on which resources under which conditions.

When a request arrives, OSS evaluates all relevant policies, including bucket policies and RAM policies. Evaluation follows the deny-first principle: any explicit Deny blocks the request regardless of Allow rules. If no matching rule exists, the request is denied by default.

Bucket policies have special rules for the bucket owner:

When the principal is set to a wildcard character (*) and the policy does not include a condition, the policy applies only to users other than the bucket owner.
When the principal is set to a wildcard character (*) and the policy includes a condition, the policy applies to all users, including the bucket owner and anonymous users. A Deny rule can make the entire bucket inaccessible. An Allow rule can expose your data to anonymous users.

If multiple statements apply to the same user, the effective permissions are the union of all statements, following the deny-first principle.

Important

The acs:SourceIp condition key matches only the source IP address of a request and does not distinguish whether the IP address is from the public network or a VPC. This means that if you use only acs:SourceIp to restrict access, requests from another VPC that uses the same IP address range are also allowed, which creates a risk of unauthorized access. Therefore, when you configure a Bucket Policy, if you specify acs:SourceIp, you must also specify acs:SourceVpc to explicitly identify the network source of the request.
This constraint applies only to new Bucket Policies. Existing Bucket Policies are not affected. However, modifying an existing Bucket Policy is treated as a new submission and is subject to this constraint.

Configure a bucket policy

OSS provides two configuration methods: graphical and syntax.

Graphical method: Form-based interface for common authorization scenarios.
Syntax method: JSON-based editor that supports all policy features and complex condition combinations.

Graphical method

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

Select Add in GUI, and then click Authorize.

Parameter	Description
Applied To	Select whether to grant permissions on the Whole Bucket or on Specific Resources.
Resource Paths	If you set Applied To to Whole Bucket, Resource Paths is set to `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 to grant permissions to. *All Accounts (): Grants permissions to anyone, including an anonymous user. RAM User: Select a RAM user that belongs to the current Alibaba Cloud account. The logged-in account must be an Alibaba Cloud account (root account) or a RAM user with bucket management permissions and the `ListUsers` permission in RAM. Otherwise, the RAM user list is not visible. Other Accounts: Enter the UID of another account or RAM user to authorize, or a temporary user with credentials that start with `arn:sts`, such as `arn:sts::1798**********:assumed-role/role-name/session-name`. You can authorize multiple users. Enter one user per line. If permissions are granted to a RAM role, the role cannot access resources from the OSS console. Use ossutil, an SDK, or an API instead.
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. Advanced Settings: Customize the Effect (Allow or Reject) and the Operation.
Condition (Optional)	Set the conditions under which the policy takes effect. Access Method: Options include HTTPS and HTTP. After 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 that belongs to the current account or enter a VPC that belongs to another account. If you select this option, the policy takes effect only for access requests from the specified VPC. VPC ≠: Select a VPC that belongs to the current account or enter a VPC that belongs to 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).

After you confirm that the configuration is correct, click OK to apply the Bucket Policy.

Syntax method

Go to the Buckets list and click the target bucket.
In the left-side navigation pane, 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: Deny the user 20214760404935xxxx all operations on example-bucket if an access request does not originate from the VPC 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. It contains one or more specific rules. Each rule includes an Effect, an Action, a Principal, a Resource, and a Condition.

Policy element	Description	Meaning in example
Effect	The effect of the policy. Valid values are `Allow` and `Deny`.	Denies 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. Setting the Principal field to an empty list (`Principal:[]`) is identical to setting it for all accounts (`Principal:["*"]`).	The policy applies only to the RAM user `20214760404935xxxx`.
Resource	The resources to which the policy applies.	The policy applies to the `example-bucket` 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 (an AND relationship).	This Deny policy takes effect only when the source VPC of the request is not `vpc-t4nlw426y44rd3iq4xxxx`.

Complete policy element reference: Authorization syntax and elements.

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

Configure a vector bucket policy

Vector buckets support only the syntax method for bucket policy configuration.

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

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

Example policy: Grant the user 20816353761158**** permission to read and write vector data for 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 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. It contains one or more specific rules. Each rule includes an Effect, an Action, a Principal, a Resource, and a Condition.

Policy element	Description	Meaning in example
Effect	The effect of the policy. Valid values are `Allow` and `Deny`.	Allows 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. Setting the Principal field to an empty list (`Principal:[]`) is identical to setting it for all accounts (`Principal:["*"]`).	The policy applies only to the RAM user `20816353761158****`.
Resource	The resources to which the policy applies.	The policy applies to the `indextest` index table in the `vector-bucket-example` bucket.
Condition	The conditions under which the policy takes effect. When you configure multiple conditions, all conditions must be met (an AND relationship).	None.

Complete policy element reference: Authorization syntax and elements.

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

Configure an OSS-HDFS policy

To ensure that OSS-HDFS service users can access the .dlsdata/ directory and its objects, do not set the authorized operation to Deny Access when you configure a Bucket Policy for an OSS-HDFS-enabled bucket. Prerequisites for using OSS-HDFS.

To restrict access to specific network IP addresses or a VPC, add the following condition to all Deny statements. This ensures the OSS-HDFS backend service can read from and write to the bucket over the classic network.

"StringNotLike": {
    "oss:ClassicIntranet": [
        "true"
    ]
}

Common scenarios: Granting permissions

The following scenarios demonstrate granting access to specific users, roles, or all users. Each includes a policy example you can adapt.

Scenario 1: Grant read/write permissions

Grant team members or partners read/write access to a bucket. This example grants read/write permissions on example-bucket to RAM users 27737962156157xxxx and 20214760404935xxxx.

Note

This policy does not grant permission to list buckets. The RAM users cannot browse the Buckets page directly. Instead, they can add the target bucket to My Favorite Paths > + in the left-side navigation pane.

{
    "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 to specific directories

Grant read-only access to specific directories. This example grants the RAM user 20214760404935xxxx read-only permissions on directories with prefixes hangzhou/2020 and shanghai/2015 in example-bucket.

Note

This policy does not grant permission to list buckets. The RAM users cannot browse the Buckets page directly. Instead, they can add the target bucket to My Favorite Paths > + in the left-side navigation pane.

{
    "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 view and list permissions

Allow a user to view bucket information and list objects. This example grants a RAM user view and list permissions on example-bucket.

Note

This policy does not grant permission to list buckets. The RAM users cannot browse the Buckets page directly. Instead, they can add the target bucket to My Favorite Paths > + in the left-side navigation pane.

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

Scenario 4: Grant read permissions to a RAM role

Grant temporary access to bucket objects through a RAM role. A RAM user or application assumes the role to obtain temporary credentials. This example grants read permissions on all objects in example-bucket to all sessions under one RAM role and a specific session under another.

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 list permissions to all users

Allow all users to list objects without accessing their content. This example grants all users (*) list permissions on example-bucket.

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

Common scenarios: Restricting network access

The following scenarios restrict bucket access based on network source (public IP or VPC) using the acs:SourceIp and acs:SourceVpc condition keys. The table below summarizes common approaches.

Access source	Policy approach	Scenario
Any VPC	Deny requests where acs:SourceVpc does not start with `vpc-*`.	Scenario 1: Restrict public network access
Specific VPC	Deny requests where acs:SourceVpc is not equal to the specified VPC ID.	Scenario 2: Restrict access to a specific VPC
Specific public IP	Statement 1 denies public network requests from unspecified IP addresses; Statement 2 denies all VPC requests.	Scenario 3: Restrict access to a specific public IP address
Specific IP range within a specific VPC	Statement 1 denies requests from unspecified VPCs; Statement 2 denies requests from unspecified IP ranges within the specified VPC.	Scenario 4: Restrict access to an IP range in a VPC
Specific public IP or specific VPC	Statement 1 denies public network requests from unspecified IP addresses; Statement 2 denies VPC requests from unspecified VPCs.	Scenario 5: Restrict access to a public IP or VPC
All except a specific IP (blacklist)	Deny requests from the specified IP, and use a wildcard `*` for SourceVpc to satisfy the constraint.	Scenario 6: Set an IP blacklist

Scenario 1: Restrict public network access

Block all public network access to a bucket by adding a deny statement with the acs:SourceVpc condition key. This statement denies requests that do not originate from a VPC. The following example denies all non-VPC access to example-bucket.

{
  "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 2: Restrict access to a specific VPC

Restrict bucket access to a specific VPC using the acs:SourceVpc condition key. This statement blocks requests from other VPCs or the public network. The following example denies all users outside VPC t4nlw426y44rd3iq4xxxx from reading objects in example-bucket.

Note

Because the principal in the following deny statement is a wildcard character (*) and a condition is included, the deny statement applies to all users, including the bucket owner.
The following deny statement only restricts access and does not grant any permissions. If the principal has not been granted permissions, you can add an allow statement to grant the necessary permissions.

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

Scenario 3: Restrict access to a specific public IP address

To restrict bucket access to a specific public IP address, create two deny statements:

Statement 1 (Deny public network requests from unspecified IP addresses): This statement uses StringNotLike: {"acs:SourceVpc": "vpc-*"} to identify public network requests (the acs:SourceVpc value for a public network request does not start with vpc-). It then uses NotIpAddress: {"acs:SourceIp": "..."} to deny requests that are not from the specified IP address. The deny action is triggered when both conditions are met.
Statement 2 (Deny all VPC requests): This statement uses StringLike: {"acs:SourceVpc": "vpc-*"} to match and deny all requests from any VPC, as the goal is to allow access only from the specified public IP address.

A request is denied if it matches either statement. The following example denies read access to example-bucket for all users except those from public IP 203.0.113.5.

Note

Because the principal in the following deny statement is a wildcard character (*) and a condition is included, the deny statement applies to all users, including the bucket owner.
The following deny statement only restricts access and does not grant any permissions. If the principal has not been granted permissions, you can add an allow statement to grant the necessary permissions.

{
  "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 4: Restrict access to an IP range in a VPC

To restrict bucket access to a specific IP range within a specific VPC, create two deny statements:

Statement 1 (Deny all requests from outside the specified VPC): This statement uses StringNotEquals: {"acs:SourceVpc": "..."} to deny requests from other VPCs and the public network.
Statement 2 (Deny requests from outside the specified IP range within the VPC): This statement uses StringEquals: {"acs:SourceVpc": "..."} to match requests from the specified VPC and then uses NotIpAddress: {"acs:SourceIp": "..."} to deny requests from outside the specified IP address range. The deny action is triggered when both conditions are met.

A request is denied if it matches either statement. The following example denies read access to example-bucket for all users except those from the 192.168.0.0/16 range within VPC t4nlw426y44rd3iq4xxxx.

Note

Because the principal in the following deny statement is a wildcard character (*) and a condition is included, the deny statement applies to all users, including the bucket owner.
The following deny statement only restricts access and does not grant any permissions. If the principal has not been granted permissions, you can add an allow statement to grant the necessary 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 5: Restrict access to a public IP or VPC

To restrict bucket access to a specific public IP or a specific VPC, create two deny statements:

Statement 1 (For public network requests, deny unspecified IPs): This statement uses StringNotLike: {"acs:SourceVpc": "vpc-*"} to identify public network requests and then uses NotIpAddress: {"acs:SourceIp": "..."} to deny requests from unspecified public IP addresses. The deny action is triggered when both conditions are met. VPC requests do not match this statement because their acs:SourceVpc value starts with vpc-.
Statement 2 (For VPC requests, deny unspecified VPCs): This statement uses StringLike: {"acs:SourceVpc": "vpc-*"} to identify VPC requests and then uses StringNotEquals: {"acs:SourceVpc": "..."} to deny requests from unspecified VPCs. The deny action is triggered when both conditions are met. Public network requests do not match this statement because their acs:SourceVpc value does not start with vpc-.

A request is denied if it matches either statement. The following example denies read access to example-bucket for all users except those from public IP 203.0.113.5 or VPC t4nlw426y44rd3iq4xxxx.

Note

Because the principal in the following deny statement is a wildcard character (*) and a condition is included, the deny statement applies to all users, including the bucket owner.
The following deny statement only restricts access and does not grant any permissions. If the principal has not been granted permissions, you can add an allow statement to grant the necessary 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 6: Set an IP blacklist

Block access from specific IP addresses or ranges by adding a deny statement to the bucket policy.

The StringLike: {"acs:SourceVpc": "*"} condition uses a wildcard to match all values and does not restrict VPC scope. It exists only to satisfy the constraint that acs:SourceIp requires a corresponding acs:SourceVpc condition.

Note

Because the principal in the following deny statement is a wildcard character (*) and a condition is included, the deny statement applies to all users, 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": [
          "*"
        ]
      }
    }
  }]
}

Common scenarios: Security controls

The following scenarios enforce security controls: credential restrictions, public access prevention, and retention policy limits.

Scenario 1: Require temporary credentials for API calls

Require temporary access credentials for API calls. This policy uses the acs:AccessId condition key to block access from long-term credentials (Alibaba Cloud account or RAM user access keys). The following example denies all users without temporary credentials (starting with TMP. or STS.) from viewing example-bucket and listing its objects.

{
    "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 2: Prohibit public ACLs

Prevent bucket and object ACLs from being set to public. 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 a public-read or public-read-write ACL triggers the deny rule.
Use the oss:x-oss-object-acl condition key to create a deny statement that prevents an object ACL from being set to any permission other than private and default.

A request is denied if it matches either statement. The following example denies public ACL operations on 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"
                    ]
                }
            }
        }
    ]
}

Scenario 3: Limit ObjectWorm retention period

After you enable an object-level retention policy (ObjectWorm) for a bucket, use a bucket policy to limit the maximum retention period. The following example limits retention to 30 days. Any PutObjectRetention request exceeding 30 days is denied.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "oss:PutObjectRetention"
      ],
      "Principal": [
        "*"
      ],
      "Resource": [
        "acs:oss:*:174649585760xxxx:example-bucket/*"
      ],
      "Condition": {
        "NumericGreaterThan": {
          "oss:object-remaining-retention-days": "30"
        }
      }
    }
  ]
}

Note

oss:object-remaining-retention-days is the condition key for an ObjectWorm policy. It represents the number of remaining retention days specified in the request.
Because the principal in this policy is a wildcard character (*) and a condition is included, the policy applies to all users, including the bucket owner.

Development and tool integration

Beyond the console, you can configure bucket policies using graphical tools, CLI tools, and SDKs.

Use the graphical tool ossbrowser

ossbrowser provides a visual, console-like experience for bucket-level policy operations. Install and sign in to ossbrowser, then configure the policy.
Use the command-line tool ossutil

Set the authorization policy using 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

Configure policies using SDKs such as Java SDK, Python SDK, Go SDK, and Node.js SDK. The SDK reference covers all supported languages.
Call an API directly

Call the PutBucketPolicy operation to set a bucket authorization policy.

Quotas and limits

Policy size: A bucket can have multiple Bucket Policy statements, but 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.

How it works

Configure a bucket policy

Graphical method

Syntax method

Configure a vector bucket policy

Configure an OSS-HDFS policy

Common scenarios: Granting permissions

Scenario 1: Grant read/write permissions

Scenario 2: Grant read-only permissions to specific directories

Scenario 3: Grant view and list permissions

Scenario 4: Grant read permissions to a RAM role

Scenario 5: Grant list permissions to all users

Common scenarios: Restricting network access

Scenario 1: Restrict public network access

Scenario 2: Restrict access to a specific VPC

Scenario 3: Restrict access to a specific public IP address

Scenario 4: Restrict access to an IP range in a VPC

Scenario 5: Restrict access to a public IP or VPC

Scenario 6: Set an IP blacklist

Common scenarios: Security controls

Scenario 1: Require temporary credentials for API calls

Scenario 2: Prohibit public ACLs

Scenario 3: Limit ObjectWorm retention period

Development and tool integration

Quotas and limits

Related documents