Examples of configuring bucket policies to allow or deny user access to OSS - Object Storage Service

A bucket policy allows you to allow or deny access of anonymous users or identified users, such as Alibaba Cloud accounts, RAM users, and RAM roles, to specific Object Storage Service (OSS) resources. For example, you can grant read-only permissions on specific OSS resources to a RAM user of another Alibaba Cloud account.

Description

Compared with a RAM policy, a bucket policy contains an additional Principal element that specifies the users who are allowed or denied access to specific OSS resources. Bucket policies allow you to manage access permissions of multiple users on resources in a centralized manner, without configuring separate permissions for each of the users. For example, you can match specific RAM users by specifying their UIDs in the Principal element or match all users by setting the Principal element to an asterisk (*).

Usage notes

If you set the Principal element to an asterisk (*) and specify the Condition element when you configure a bucket policy, the bucket policy takes effect for all users including the bucket owner. In this case, if an access request triggers the Deny statement, the request is denied, even if the request was made by the bucket owner, who has all access permissions on the bucket and objects in it by default.
If you set the Principal element to an asterisk (*) and do not specify the Condition element when you configure a bucket policy, the bucket policy takes effect for all users except the bucket owner. In this case, the Deny statement is not triggered for the bucket owner, who has all access permissions on the bucket and objects in it by default.

Example 1: Grant specific RAM users read and write access to a bucket

If you want to grant specific members of your team or partners the permissions to upload, download, and manage objects in a bucket, you can configure a bucket policy to grant the permissions to these members. You do not need to configure access policies for each RAM user. The following example policy grants the RAM users whose UIDs are 27737962156157xxxx and 20214760404935xxxx the permissions to read and write a bucket named examplebucket.

Important

In the following Allow statement, the RAM users are not granted the permissions to list buckets. The RAM users cannot view any buckets or enter the authorized bucket from the Buckets page in the OSS console. The RAM user can access the bucket by adding it to the favorite paths. For more information, see OSS access paths.

{
    "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:examplebucket/*"
            ]
        },
        {
            "Effect":"Allow",
            "Action":[
                "oss:ListObjects"
            ],
            "Principal":[
                "27737962156157xxxx",
                "20214760404935xxxx"
            ],
            "Resource":[
                "acs:oss:*:174649585760xxxx:examplebucket"
            ],
            "Condition":{
                "StringLike":{
                    "oss:Prefix":[
                        "*"
                    ]
                }
            }
        }
    ]
}

Example 2: Grant specific RAM users the permissions to read specific directories of a bucket

If you want to protect specific project objects in a bucket from tampering and allow specific project members to list and read these objects, you can grant the members the permissions to list and read the project objects. The following example policy grants a RAM user whose UID is 20214760404935xxxx the permissions to read the hangzhou/2020 and shanghai/2015 directories of a bucket named examplebucket.

Important

In the following Allow statement, the RAM user is not granted the permissions to list buckets. The RAM user cannot view any buckets or enter the authorized bucket from the Buckets page in the OSS console. The RAM user can access the bucket by adding it to the favorite paths. For more information, see OSS access paths.

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

Example 3: Grant all users the permissions to only list all objects in a bucket

If your bucket is used for public resource sharing and you want all users to be able to view object names but not object content, you can set the Principal element to an asterisk (*) and grant all users the permissions to list all objects in the bucket. The following example policy grants all users the permissions to only list all objects in a bucket named examplebucket.

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

Example 4: Grant specific RAM users the permissions to view information about a bucket and list all objects in the bucket

If you want to grant specific members of your team or partners the permissions to view information about a bucket and list all objects in the bucket, you can configure a bucket policy to grant the permissions to the RAM users that correspond to these members. You do not need to configure access policies for each RAM user. The following example policy grants specific RAM users the permissions to view information about a bucket named examplebucket and list objects in the bucket.

Important

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

Example 5: Grant specific RAM roles the permission to read objects in a bucket

If a RAM user or application requires temporary access to objects in your bucket, you can create a RAM role and assign the required permissions to the RAM role. The RAM user or application can assume the RAM role to obtain temporary access credentials that can be used to access objects in your bucket. The following example policy allows two RAM roles of an Alibaba Cloud account to read all objects in a bucket named examplebucket. One RAM role can access objects in the bucket only from the specified session, and the other can access objects in the bucket from all sessions.

Important

When you use a bucket policy to grant permissions to a RAM role, specify the Principal element in the arn:sts::<uid>:assumed-role/<role-name>/<session-name> format. The values of<role-name>and<session-name>are case-sensitive.

{
    "Version": "1",
    "Statement": [
        {
            "Action": [
                "oss:GetObject"
            ],
            "Effect": "Allow",
            "Principal": [
                "arn:sts::10323xxxxx72056:assumed-role/okrole/sessiontest",
                "arn:sts::10323xxxxx72056:assumed-role/secondrole/*"
            ],
            "Resource": [
                "acs:oss:*:1032xxxxx672056:examplebucket/*"
            ]
        }
    ]
}

Example 6: Restrict access to a specific VPC

If you want to allow access to a bucket only from a specific virtual private cloud (VPC), you can specify the acs:SourceVpc parameter as a condition and add a Deny statement to the bucket policy to reject requests from other VPCs or the Internet. Requests from other VPCs do not match the specified condition and the Deny statement in the bucket policy is triggered. Requests from the Internet do not match the specified condition because the requests do not contain any VPC information and the Deny statement in the bucket policy is triggered. The following example policy denies all object read requests to a bucket named examplebucket from all sources other than the VPC that is identified by the t4nlw426y44rd3iq4xxxx ID.

Important

In the following Deny statement, the Principal element is an asterisk (*) and the Condition element is specified. In this case, the Deny effect takes effect on all users, including the bucket owner. If the bucket owner, who has full permissions on the bucket by default, initiates a request to read objects in the bucket by using another VPC, the request is also rejected.
The following Deny statement is used only to deny access and does not grant access permissions. If the authorization principal has not been granted access permissions, you can add an Allow statement.

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

Example 7: Restrict access to a specific public IP address

If you want to allow access to a bucket only from a specific public IP address, you can specify the acs:SourceIp parameter as a condition and add a Deny statement to the bucket policy to reject requests from VPCs or other public IP addresses. Requests from other public IP addresses do not match the specified conditions and the Deny statement in the bucket policy is triggered. Requests from VPCs do not match the specified conditions and the Deny statement in the bucket policy is triggered. The following example policy rejects requests to read objects in a bucket named examplebucket from users who do not use the 203.0.113.5 public IP address.

Important

In the following Deny statement, the Principal element is an asterisk (*) and the Condition element is specified. In this case, the Deny effect takes effect on all users, including the bucket owner. If the bucket owner, who has full permissions on the bucket by default, initiates a request to read objects in the bucket by using another public IP address, the request is also rejected.
The following Deny statement is used only to deny access and does not grant access permissions. If the authorization principal has not been granted access permissions, you can add an Allow statement.

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

Example 8: Restrict access to a specific CIDR block of a VPC

If you want to allow access to a bucket only from a specific CIDR block of a VPC, you can add the following Deny statements to the bucket policy:

Specify the acs:SourceVpc parameter as a condition and add a Deny statement to the bucket policy to reject requests from other VPCs or the Internet. Requests from other VPCs do not match the specified conditions and the Deny statement in the bucket policy is triggered. Requests from the Internet do not match the specified conditions because the requests from the Internet do not contain VPC information and the Deny statement in the bucket policy is triggered.
Specify the acs:SourceIp and acs:SourceVpc parameters as a condition and add a Deny statement to the bucket policy to reject requests from other CIDR blocks of VPCs.

After you add the preceding two Deny statements to the bucket policy, the logical relationship between the two statements is OR. If one of the preceding conditions is met, access is denied. The following example policy denies requests to read objects in a bucket named examplebucket except for the requests from the 192.168.0.0/16 CIDR block of VPC t4nlw426y44rd3iq4xxxx.

Important

In the following Deny statement, the Principal element is an asterisk (*) and the Condition element is specified. In this case, the Deny effect takes effect on all users, including the bucket owner. If the bucket owner, who has full permissions on the bucket by default, initiates a request to read objects in the bucket by using another CIDR block of a VPC, the request is rejected.
The following Deny statement is used only to deny access and does not grant access permissions. If the authorization principal has not been granted access permissions, you can add an Allow statement.

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

Example 9: Restrict access to a specific public IP address or VPC

If you want to allow access to a bucket only from a specific public IP address or VPC, you can add the following Deny statements to the bucket policy:

Specify the acs:SourceIp parameter as a condition and add a Deny statement to the bucket policy to reject requests from other public IP addresses. However, the VPC has IP addresses, and you also want to allow access to the bucket from a specific VPC at the same time. When you reject requests from other public IP addresses, you must specify the acs:SourceVpc parameter and the StringNotLike operator to prevent the requests from the specified VPC from being rejected.
Specify the acs: SourceVpc parameter as a condition and add a Deny statement to the bucket policy to reject requests from other VPCs. Requests from public IP addresses do not contain VPC information and are rejected based on the VPC condition. To allow requests from the specified public IP address, you must specify the acs:SourceVpc parameter and the StringLike operator to prevent the specified IP address from being denied.

After you add the preceding two Deny statements to the bucket policy, the logical relationship between the two statements is OR. If one of the preceding conditions is met, access is denied. The following example policy denies all users except for the users whose IP address is 203.0.113.5 or the users whose VPC ID is t4nlw426y44rd3iq4xxxx to read files from the destination bucket examplebucket.

Important

In the following Deny statement, the Principal element is an asterisk (*) and the Condition element is specified. In this case, the Deny effect takes effect on all users, including the bucket owner. If the bucket owner, who has full permissions on the bucket by default, initiates a request to read objects in the bucket by using another public IP address or another VPC, the request is rejected.
The following Deny statement is used only to deny access and does not grant access permissions. If the authorization principal has not been granted access permissions, you can add an Allow statement.

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

Example 10: Restrict API-based access to users that use temporary access credentials

If you want to restrict API-based access to users that use temporary access credentials, you can specify acs:AccessId as a condition and add a Deny statement to the bucket policy to block access by using non-temporary access credentials such as the AccessKey pair of an Alibaba Cloud account or RAM user. Access requests that use non-temporary access credentials trigger the Deny statement. The following example policy denies object read and list requests to a bucket named examplebucket except for read and list requests from users that use temporary access credentials.

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

References

For more information about elements of a bucket policy, see RAM policies.
For more information about how to configure a bucket policy, see Bucket policies.
For more information about how to grant other users specific permissions to access OSS resources, see Authorization.