Configure an authorization policy using Bucket Policy - Object Storage Service

A bucket policy is a resource-based access control policy for a bucket that grants access to other Alibaba Cloud accounts, RAM users, or anonymous users. You can use a bucket policy to configure cross-account authorization, anonymous access control, and access restrictions based on IP addresses or VPCs.

How it works

A bucket policy uses a resource-based authorization model. The policy is attached directly to a bucket and defines which principals can perform which actions on which resources under what conditions.

When a user makes an access request, OSS evaluates all relevant policies, including the bucket policy and any applicable RAM policies. Permission evaluation follows the deny-first principle: an explicit Deny statement in any policy immediately blocks the request and overrides all Allow statements. If no policy explicitly allows or denies access, access 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, 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, the policy applies to all users, including the bucket owner and anonymous users. This means a Deny rule will also block the bucket owner, potentially making the entire bucket inaccessible, and an Allow rule grants access to anonymous users, potentially exposing your data publicly.

If you configure multiple bucket policy rules for the same user, their permissions are a combination of all the rules, subject to the deny-first principle.

Important

When you specify acs:SourceIp in a bucket policy, you must also specify acs:SourceVpc.

Configure a bucket policy

OSS provides a graphical policy method and a syntax-based policy approach to meet different configuration needs.

Graphical policy method: This method provides an intuitive, form-based experience for common authorization scenarios and simplifies the configuration process.
Syntax-based policy approach: This method allows you to write a complete authorization policy in JSON format. It supports all advanced features and complex condition combinations, offering maximum configuration flexibility.

Graphical policy

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

Select Add in GUI, and then click Authorize to configure the authorization settings.

Parameter	Description
Applied To	Select whether to apply the policy to the Whole Bucket or 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 paths to the directories or individual objects that you want to authorize. You can add multiple resource paths.
Authorized User	Specify the principal to grant permissions to. *All Accounts (): Grants permissions to any user, including any anonymous visitor. RAM User: Select a RAM user that belongs to your Alibaba Cloud account. To view the list of RAM users, you must be logged in as an Alibaba Cloud account or a RAM user that has administrative permissions on the bucket and the `ListUsers` permission in the RAM console. Other Accounts: Enter the UIDs of other Alibaba Cloud accounts or RAM users, or the ARN of an assumed role session that starts with `arn:sts`, such as `arn:sts::1798**********:assumed-role/role-name/session-name`. You can grant permissions to multiple users. Enter one user per line. A RAM role with these permissions can access the authorized resources via tools such as the ossutil command line interface, SDKs, or APIs, but not from the OSS console.
Authorized Operation	Simple Settings: Select a predefined set of common operations. Options include Read-Only (excluding ListObject), Read-Only (including ListObject), Read/Write, Full Access, and Deny Access. Important To ensure that users of the OSS-HDFS service can access the `.dlsdata/` directory and any object within it, do not set the authorized operation to Deny Access when you configure a Bucket Policy for a bucket with the OSS-HDFS service enabled. If you must restrict access based on specific IP addresses or VPCs for security reasons, you must add corresponding conditions. For more information, see Notes on using OSS-HDFS. 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. If you select an option, the policy applies only to access requests that use the selected method. IP =: Enter a list of IP addresses. If you select this option, the policy applies only to access requests from the specified IP addresses. IP ≠: Enter a list of IP addresses. If you select this option, the policy applies only to access requests that are not from the specified IP addresses. VPC =: Select a VPC of the current account or enter the ID of a VPC that belongs to another account. If you select this option, the policy applies only to access requests from the specified VPC. VPC ≠: Select a VPC of the current account or enter the ID of a VPC that belongs to another account. If you select this option, the policy applies only to access requests that are not from the specified VPC. If you configure multiple conditions, they are evaluated using a logical AND. The policy applies only if all conditions are met.

Review your settings and click OK to apply the Bucket Policy.

Syntax policy

Go to the Buckets list and click 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 the authorization policy in JSON format.

Example: The following policy denies the RAM user 20214760404935xxxx all operations on example-bucket for requests not originating from 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 consists of a Version and a Statement.

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

Statement: The main body of the policy, which contains one or more statements. Each statement includes the following elements: Effect, Action, Principal, Resource, and Condition.

Policy element	Description	Example
Effect	The effect of the policy. Valid values are `Allow` and `Deny`.	The effect is to Deny the request.
Action	The specific operation that is allowed or denied. You can use the wildcard character `*`.	Deny all OSS operations (`oss:*`).
Principal	The user, account, or service to which the policy applies. If you set Principal to an empty list (`Principal:[]`), the effect is the same as setting it to 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 bucket `example-bucket` and all objects within it.
Condition	The conditions under which the policy takes effect. If you specify multiple conditions, they are evaluated using a logical AND. The policy applies only if all conditions are met.	This Deny policy applies only when the source VPC of the request is not `vpc-t4nlw426y44rd3iq4xxxx`.

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

Review the policy and click Save. Follow the on-screen prompts to complete the process.

Configure a vector bucket policy

For vector buckets, you can configure a bucket policy only with the policy syntax.

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

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

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

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

A complete authorization policy consists of a Version and a Statement.

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

Statement: The main body of the policy, which contains one or more rules. Each rule includes the following policy elements: Effect, Action, Principal, Resource, and 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 operation on the resource. The wildcard character `*` is supported.	Read and write vector data.
Principal	The principal (user, account, or role) to which the policy applies. Setting Principal to an empty list (`Principal:[]`) is equivalent to setting it to all accounts (`Principal:["*"]`).	The policy applies only to the RAM user `20816353761158****`.
Resource	The cloud resources that the policy statement affects.	The policy applies to the `indextest` index table in the `vector-bucket-example` vector bucket.
Condition	Specifies when the policy is in effect. If you specify multiple conditions, they are evaluated using a logical AND. The policy takes effect only if all conditions are met.	None.

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

Review the authorization policy and then click Save.

Common authorization scenarios

The following scenarios demonstrate common use cases for a bucket policy, covering permission grants, access restrictions, and security controls. Each scenario provides a complete policy configuration that you can customize for your specific requirements.

Scenario 1: Grant read and write permissions to RAM users

When you need to allow specific team members or partners to upload, download, and manage objects in a bucket, you can use a bucket policy to grant the necessary permissions to those RAM users. The following policy grants read and write permissions on the bucket example-bucket to the RAM users with the UIDs 27737962156157xxxx and 20214760404935xxxx.

Note

Because this policy does not grant the RAM users permission to list buckets, the specified RAM users cannot view all buckets on the Buckets page or click a bucket to open it. The specified RAM users can add and access the target bucket from 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 specific directory

To allow project members to read specific objects in a bucket while preventing modification, you can grant read-only permissions to the corresponding RAM user. The following policy grants read-only permissions on specific directories (with prefixes hangzhou/2020 and shanghai/2015) in the bucket example-bucket to the RAM user with the 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 permissions to view buckets and list objects

To allow specific team members or partners to view all information about a bucket and list its objects, use a bucket policy to grant the necessary permissions to the RAM user. The following policy grants a specified RAM user permissions to view all information about the bucket example-bucket and list the objects 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 read permissions to a RAM role

When you need to allow a RAM user or an application to temporarily access objects in a bucket, you can create a RAM role and grant it the necessary permissions. The RAM user or application can then assume the role to obtain temporary access credentials to read the objects. The following policy grants all sessions under one RAM role and a specific session under another RAM role permissions to read all objects 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 objects

When a bucket is used for sharing public resources and you want to allow all visitors to view object names but not access the actual object content, you can set the Principal to a wildcard character (*) and grant permissions to list all objects. The following policy grants all visitors permissions to list all objects in the bucket example-bucket.

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

Scenario 6: Restrict public network access

To prevent access to a specific bucket from the public network, you can use the acs:SourceVpc condition key to create a deny statement and add it to the bucket policy. This statement blocks requests that do not originate from a VPC network. The following policy denies all visitors outside a VPC network access to the bucket 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 7: Restrict access to a specific VPC

To restrict access to a bucket to only a specific VPC, you can use the acs:SourceVpc condition key to create a deny statement and add it to the bucket policy. This statement blocks requests from other VPCs or the public network. The following policy denies read access to objects in the bucket example-bucket for all visitors outside the specified VPC with the ID 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 visitors, including the bucket owner.
This deny statement only restricts access and does not grant any permissions. To grant access to a principal, you must also add a separate allow statement.
If the OSS-HDFS service is enabled, you must add the following condition to all deny statements to ensure that the OSS-HDFS background service can read from 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: Restrict access to a specific IP address

To restrict access to a bucket to a specific public IP address, use the acs:SourceIp condition key to create a deny statement and add it to the bucket policy. This statement blocks requests from other public IP addresses. The following policy denies all visitors except those from the public IP address 203.0.113.5 permission to perform read operations on 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 visitors, including the bucket owner.
This deny statement only restricts access and does not grant any permissions. To grant access to a principal, you must also add a separate allow statement.
If the OSS-HDFS service is enabled, you must add the following condition to all deny statements to ensure that the OSS-HDFS background service can read from 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: Restrict access by CIDR block in a VPC

To restrict access to a bucket to a specific CIDR block within a specific 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 matches the conditions in either statement. The following policy denies all visitors outside the specified CIDR block (192.168.0.0/16) of the specified VPC with the ID t4nlw426y44rd3iq4xxxx permission to perform read operations on objects in the bucket 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 visitors, including the bucket owner.
This deny statement only restricts access and does not grant any permissions. To grant access to a principal, you must also add a separate allow statement.
If the OSS-HDFS service is enabled, you must add the following condition to all deny statements to ensure that the OSS-HDFS background service can read from 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: Restrict access by IP address or VPC

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

Use the acs:SourceIp condition key to create a deny statement that blocks requests from other public IP addresses, and also use 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 statement to block requests from other VPCs, and use the StringLike condition operator with the acs:SourceVpc key to exclude requests from specified public IP addresses to prevent them from being incorrectly denied because they do not meet the specified VPC ID condition.

After you add these two deny statements to the bucket policy, a request is denied if it meets either condition. The following policy denies all visitors outside the specified public IP address (203.0.113.5) or the specified VPC with the ID t4nlw426y44rd3iq4xxxx permission to perform read operations on objects in the bucket 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 visitors, including the bucket owner.
This deny statement only restricts access and does not grant any permissions. To grant access to a principal, you must also add a separate allow statement.
If the OSS-HDFS service is enabled, you must add the following condition to all deny statements to ensure that the OSS-HDFS background service can read from 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 specific IP addresses access to a bucket and its objects, you can use an IP blacklist policy. By adding a deny statement to 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 a Condition is included, the deny statement applies to all visitors, including the bucket owner.
You can configure multiple IP addresses and CIDR blocks. 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

To require that API calls use temporary access credentials when accessing bucket resources, you can use the acs:AccessId condition key to create a deny statement and add it to the bucket policy. This statement blocks access methods that use non-temporary credentials, such as a long-term access key of an Alibaba Cloud account or a RAM user. The following policy denies all visitors except those who use temporary access credentials (starting with TMP. or STS.) permission to view the bucket example-bucket and list 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 13: Prohibit public bucket and object ACLs

To prohibit setting bucket and object ACLs to public access, 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.
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 policy denies operations that set public access permissions on the 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"
                    ]
                }
            }
        }
    ]
}

Scenario 14: Restrict the maximum ObjectWorm retention period

After you enable object-level retention policies (ObjectWorm) for a bucket, you can use a bucket policy to limit the maximum retention period. For example, the following policy limits the retention period to a maximum of 30 days. Any PutObjectRetention request that specifies a retention period longer than 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 a condition key for ObjectWorm retention policies. 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

You can configure a bucket policy manually in the console, or with graphical tools, command-line tools, and SDKs.

Use the graphical tool ossbrowser

ossbrowser provides a console-like visual interface for managing bucket policies. To configure a policy, install and log on to ossbrowser and follow the on-screen instructions.
Use the command-line tool ossutil

Use the put-bucket-policy command to set an authorization policy.

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 with SDKs for various programming languages, including the Java SDK, Python SDK, Go SDK, and Node.js SDK. For a complete list of supported SDKs, see the SDK Reference.
Call an API directly

Call the PutBucketPolicy operation to set an authorization policy for a bucket.

Quotas and limits

Policy size: A bucket can have multiple bucket policies, but their combined size cannot exceed 16 KB.
Field length: Each field in a bucket policy cannot exceed 4,095 bytes.

Object Storage Service:Bucket Policy

How it works

Configure a bucket policy

Graphical policy

Syntax policy

Configure a vector bucket policy

Common authorization scenarios

Scenario 1: Grant read and write permissions to RAM users

Scenario 2: Grant read-only permissions on a specific directory

Scenario 3: Grant permissions to view buckets and list objects

Scenario 4: Grant read permissions to a RAM role

Scenario 5: Grant all visitors permission to list objects

Scenario 6: Restrict public network access

Scenario 7: Restrict access to a specific VPC

Scenario 8: Restrict access to a specific IP address

Scenario 9: Restrict access by CIDR block in a VPC

Scenario 10: Restrict access by IP address or VPC

Scenario 11: Configure an IP blacklist

Scenario 12: Require temporary credentials for API calls

Scenario 13: Prohibit public bucket and object ACLs

Scenario 14: Restrict the maximum ObjectWorm retention period

Development and tool integration

Quotas and limits

Related documents