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. After you add or modify a bucket policy using the syntax method, the corresponding policy entry is synchronously displayed in the graphical view. Policies configured using either method are linked and stay in sync with each other. The Resource field in a policy specifies the scope of resources to which the authorization applies.

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": [
        {
            "Sid": "DenyNonVpcAccess",
            "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 supports an optional Sid, and includes an Effect, an Action, a Principal, a Resource, and a Condition.

Policy element	Description	Meaning in example
Sid (optional)	Statement ID. A human-readable, unique identifier for each statement in the policy. It helps with differentiation, management, and auditing, and does not affect the permissions themselves.	Identifies the deny statement as `DenyNonVpcAccess`.
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.

The syntax method lets you specify one or more individual actions (for example, oss:DeleteObject), so the resulting permission scope can be narrower than Full Access (equivalent to oss:*) under Simple Settings in the graphical method. Advanced Settings in the graphical method also lets you specify individual actions, achieving the same level of granularity as the syntax method. For the permissions that correspond to each action, see the OSS API reference.

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> must be all lowercase.

{
    "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"
            ]
        }
    ]
}

Scenario 6: Access OSS over the internal network from an ECS instance without an AccessKey pair

When you access OSS over an internal endpoint from an ECS instance in the same region, whether additional authorization is required depends on the read/write permissions of the destination bucket:

public-read bucket: The ECS instance can access the bucket directly over the internal URL without additional Bucket Policy configuration.
private bucket: You must configure a Bucket Policy that uses the acs:SourceVpc condition key to authorize access requests from the VPC in which the ECS instance resides.

The internal URL format is as follows. Replace bucketname with the name of the destination bucket and <region> with the region where the bucket resides (for example, cn-hangzhou):

https://bucketname.oss-<region>-internal.aliyuncs.com/objectname

Run the following command to verify that internal network access works as expected:

curl -I https://bucketname.oss-<region>-internal.aliyuncs.com/objectname

If the response returns 403 AccessDenied, the VPC of the current ECS instance has not been authorized in the Bucket Policy. Troubleshoot as follows:

Go to the Buckets page and click the destination bucket.
In the left-side navigation pane, click Permission Control > Bucket Policy, and then click Authorize.
Configure the authorization condition. Select VPC = and specify the VPC in which the ECS instance resides.
After you confirm that the authorization is correct, click OK to apply the Bucket Policy.
Confirm that the ECS instance sends requests over the internal endpoint, not the public endpoint.
Run the curl command again to verify. If the response still returns 403, check whether the VPC ID configured in the Bucket Policy VPC condition matches the VPC ID of the ECS instance.

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
Specific IP (deny download only)	Deny `GetObject` and `ListObjects` requests from the specified IP while continuing to allow `PutObject`, and use a wildcard `*` for SourceVpc to satisfy the constraint.	Scenario 7: Deny download operations from a specific IP address
Classic network	Allow classic network access.	Scenario 8: Configure classic network access

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

To restrict access from a VPC in another Alibaba Cloud account, you can replace vpc-* in the Condition of Statement 2 with the target account's VPC ID (in the format vpc-xxx, obtainable from the VPC console of the target account). The acs:SourceVpc condition key supports VPC IDs from both the current account and other Alibaba Cloud accounts.

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

The acs:SourceVpc condition key supports VPC IDs from both the current account and other Alibaba Cloud accounts, enabling cross-account VPC access control. To allow access from a specific VPC in another account, replace the VPC ID in Statement 2 with the target account's VPC ID.

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": [
          "*"
        ]
      }
    }
  }]
}

Scenario 7: Deny download operations from a specific IP address

To deny a specific IP address from downloading (GetObject) and listing (ListObjects) objects in a bucket while still allowing the IP address to upload objects (PutObject), scope the Action of the Deny statement to GetObject and ListObjects only. Unlike the IP blacklist in Scenario 6, which denies oss:*, this policy denies only download-type operations, so uploads are not affected.

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.

Because the Principal in the following Deny statement is a wildcard character (*) and the statement includes a Condition, this Deny statement applies to all requesters, 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:GetObject",
      "oss:ListObjects"
    ],
    "Principal": [
      "*"
    ],
    "Resource": [
      "acs:oss:*:174649585760xxxx:example-bucket/*",
      "acs:oss:*:174649585760xxxx:example-bucket"
    ],
    "Condition": {
      "IpAddress": {
        "acs:SourceIp": [
          "101.***.***.100"
        ]
      },
      "StringLike": {
        "acs:SourceVpc": [
          "*"
        ]
      }
    }
  }]
}

After this policy takes effect, GetObject and ListObjects requests from the denied IP address return 403 AccessDenied, while PutObject requests are not affected.

Scenario 8: Configure classic network access

The oss:ClassicIntranet condition key indicates whether a request originates from the OSS classic network. Valid values are true and false. Some OSS backend services (such as log delivery and bucket inventory) access buckets over the classic network. Use the following condition to match requests from the classic network.

"Condition": {
    "StringEquals": {
        "oss:ClassicIntranet": [
            "true"
        ]
    }
}

When configuring network access restrictions (Deny policies), to allow the backend services above, add the following condition to the Condition block of the Deny statement to exclude classic network requests and avoid unintended blocking.

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

Scenario 9: Grant read/write permissions to a specific IP address and read-only permissions to all other IP addresses

To grant read/write permissions to requests from a specific IP address range and read-only permissions to requests from all other IP addresses, you need two Allow statements. A single statement that uses only the acs:SourceIp condition key cannot be saved, because OSS requires the acs:SourceVpc condition key to be specified together with acs:SourceIp. The following example combines two statements to achieve this differentiated authorization.

Statement 1 grants read/write permissions to example-bucket for requests from the IP address range 192.168.0.0/16.
Statement 2 grants read-only permissions to example-bucket for requests from any IP address, with no condition.

{
    "Version": "1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "oss:GetObject",
                "oss:PutObject",
                "oss:ListObjects"
            ],
            "Resource": [
                "acs:oss:*:*:examplebucket",
                "acs:oss:*:*:examplebucket/*"
            ],
            "Condition": {
                "IpAddress": {
                    "acs:SourceIp": [
                        "192.168.0.0/16"
                    ]
                },
                "StringNotLike": {
                    "acs:SourceVpc": [
                        "vpc-*"
                    ]
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "oss:GetObject",
                "oss:ListObjects"
            ],
            "Resource": [
                "acs:oss:*:*:examplebucket",
                "acs:oss:*:*:examplebucket/*"
            ]
        }
    ]
}

Full validation when multiple statements coexist

When a bucket contains multiple policy statements, adding or modifying any statement triggers full validation of all statements in the policy. Every statement that contains the acs:SourceIp condition key must also contain the acs:SourceVpc condition key. Otherwise, the PutBucketPolicy operation fails and returns the error code 0030-00000008.

Troubleshooting steps:

Call GetBucketPolicy to retrieve all the statements in the current policy of the bucket.
Check the Condition element of each statement, and verify that every statement that contains acs:SourceIp also contains acs:SourceVpc.
Add the missing acs:SourceVpc condition to the statements identified in step 2, and then call PutBucketPolicy again to resubmit the policy.

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.

Diagnose anonymous uploads

When unexpected files appear in a bucket, check whether the bucket policy contains an Allow statement with Principal set to a wildcard character (*). This statement lets anyone upload objects using a script (for example, python-requests or curl) without authentication.

Enable real-time log query in the OSS console: go to the target bucket, click Log Management > Real-time Query, and then click Enable Now.

Query the access logs in Simple Log Service (SLS) and filter for anonymous uploads:

select access_id, user_agent, client_ip, http_method, object
from oss-log-store
where access_id = '-' and user_agent like '%python-requests%'

Field descriptions:
- access_id equal to - indicates an anonymous (unauthenticated) request.
- user_agent shows the tool used to upload the object, such as python-requests/2.28.1.
- client_ip is the source IP address of the anonymous upload.
Anonymous uploads have sign_type set to NotSign, while signed uploads have sign_type set to NORMAL_SIGN4. Modifying or removing the Allow statement with Principal set to * does not affect signed uploads performed through the console, ossbrowser, or ossutil.

Read-only users can still write objects

The AliyunOSSReadOnlyAccess system policy grants only read actions (oss:Get* and oss:List*) and does not include any write permissions. If a RAM user that has only this policy attached can still write objects (for example, a PutObject request returns 200 OK), the user has an overlapping write permission from another source. Check the following three sources:

RAM custom policies: Call ListPoliciesForUser to list all the policies attached to the RAM user, and check whether any custom policy grants oss:Put* or oss:*.
Bucket policy: Check the bucket policy of the target bucket. Verify whether the Principal element includes this RAM user and whether the Action element includes a write action.
RAM user group policies: If the RAM user belongs to a RAM user group, check whether the user group has a policy attached that grants write permissions.

To resolve the issue, remove or modify the overlapping write-permission policy so that the RAM user's permissions are controlled only by AliyunOSSReadOnlyAccess. After you remove the overlapping write-permission policy, requests such as PutObject from the read-only RAM user return 403 AccessDenied, with an error message similar to You have no right to access this object because of bucket acl.

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

Scenario 6: Access OSS over the internal network from an ECS instance without an AccessKey pair

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

Scenario 7: Deny download operations from a specific IP address

Scenario 8: Configure classic network access

Scenario 9: Grant read/write permissions to a specific IP address and read-only permissions to all other IP addresses

Full validation when multiple statements coexist

Common scenarios: Security controls

Scenario 1: Require temporary credentials for API calls

Scenario 2: Prohibit public ACLs

Scenario 3: Limit ObjectWorm retention period

Diagnose anonymous uploads

Read-only users can still write objects

Development and tool integration

Quotas and limits

Related documents