Bucket Policy is a resource-based authorization policy. The access policy uses the JSON-based access policy language. You can execute a specified action to a specified OSS resource by accessing the principal specified by policy language authorization.
Directly authorize other accounts to access.
You can grant other primary accounts the permission to access your OSS resources.
Authorize sub-users of other accounts to access.
You can grant sub-users of other accounts the permission to access your OSS resources.
Authorize role and access.
You can grant permissions to roles accessing your OSS resources.
Grant anonymous users the access permissions with specific restrictions.
In some scenarios, you need to grant anonymous users the access policies with IP restrictions. For example, in your website providing services externally, static files are stored in OSS to prevent chains from being stolen by others so as to generate unnecessary costs. You can set policies with Referer restrictions through Bucket policy, to specify the list of permitted accesses. If you hope that only internal access is permitted to your enterpriseтАЩs internal confidential documents, you can set access policies with IP restrictions based on Bucket Policy. In the above scenarios, if there are a large number of accessing personnel, configuring IAM Policy for each person will be required, and the workload will be huge. Then, you can authorize efficiently and conveniently with Bucket Policy.
Description: Currently, there are slight differences in syntax between the Bucket Policy elements and IAM Policy elements. Please make a distinction, and do not confuse the two. The size restriction for Bucket Policy is 16k.
The principal element is used to specify the users, accounts, role or other entities allowed or denied to access resources. The element principal only functions in the bucket; is not required to be specified in user policy, as the user policy is directly attached to a specific user. The following is an example to specify a principal in the Bucket Policy.
Description
In specifying the primary account: "AWS":"arn:aws:iam::account-ID:root", "root" can be omitted. Examples For example, if the account ID is 123456789012, you can use the following method to specify the account in the Principal element:
//Single Account "Principal":{"AWS":"arn:aws:iam::123456789012:root"} //Multiple Accounts "Principal": { "AWS": [ "arn:aws:iam::123456789012:root", "arn:aws:iam::123456789010"] }
Specify IAM sub-user:"AWS": "arn:aws:iam::account-ID:user/user-name", the user-name is the user name of the sub-user that you want to authorize
//Single IAM Sub-user "Principal": { "AWS": "arn:aws:iam::123456789012:user/user-name" } //Multiple IAM Sub-users "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/user-name-1", "arn:aws:iam::111111111111:user/UserName2"] }
Specifies the IAM roleя╝Ъ"AWS":"arn:aws:iam::accountID:role/roleName", roleName refers to the authorized role name.
//Single IAM role "Principal": { "AWS": "arn:aws:iam::123456789012:role/role-test" } //Multiple IAM roles "Principal": { "AWS": [ "arn:aws:iam::123456789012:role/role-test1", "arn:aws:iam::123456789012:role/role-test2"] }
For example, if you configure the bucket as a website, and you need to set all the objects in the bucket open for access, please do as follows: Example:
"Principal":{"AWS":"*"}
Effect means the authorization result of the Statement, which is divided into Allow and Deny. When the matching of several Statements succeeds, the priority of Deny is higher. If no access permission to resources is explicitly granted (allow), the access is implicitly denied. You can also deny the access to resources, which can guarantee that the user cannot access to the resources, even if any other policy grants the access permission. Examples
"Effect" : "Allow" //Or "Effect" : "Deny"
The list of supported Actions in Bucket policy is as follows:
Action Keyword | Action Description | Corresponding API | Action Level |
---|---|---|---|
s3:PutObject | Upload an Object to the Bucket, supporting normal upload and upload by parts, etc. | PUT Object, POST Object, PUT Object - COPY, Initiate Multipart Upload, Upload Part, Complete Multipart Upload, Abort Multipart Upload | Object Level Action |
s3:GetObject | Get an Object and its relevant information in the Bucket | GET Object, HEAD Object | Object Level Action |
s3:DeleteObject | Delete an Object in the Bucket | DELETE Object | Object Level Action |
s3:ListBucket | List the Object in the Bucket | GET Bucket (List Objects), HEAD Bucket, List Multipart Upload | Bucket Level Action |
s3:DeleteBucket | Delete the Bucket | DELETE Bucket | Bucket Level Action |
Example: For example, with s3:DeleteObject permission, a user can perform a bucket deletion operation on OSS.
For your OSS resources, the specifying methods in Bucket policy and IAM policy are slightly different, and the method to specify OSS Resource in Bucket policy: Instead of specifying regions and namespaces, relative-id specifies your OSS resources, which can be a bucket or some objects or a certain object therein. It supports wildcards (? and /*).
arn:aws:s3:::relative-id //Examples: arn:aws:s3:::bucket_name arn:aws:s3:::bucket_name/key_name
Example: For example, the bucket name is examplebucket
Resource Representation | Description |
---|---|
arn:aws:s3:::examplebucket/developers/design_info.doc | It represents objects under /developers/design_info.doc in examplebucket bucket |
arn:aws:s3:::examplebucket/* | It represents all objects in examplebucket bucket |
arn:aws:s3:::examplebucket/dir/* | It represents all objects under dir directory in examplebucket bucket |
arn:aws:s3:::examplebucket/abc* | It represents all objects prefixed with adb in examplebucket bucket |
arn:aws:s3:::example?bucket/* | It represents all objects in the bucket (such as example1bucket, example2bucket, and example3bucket.) |
Bucket policy allows you to specify a condition, which is optional, for the rule to take effect when you grant the permission. If multiple conditional operators are specified in one Condition, then multiple conditional operators are of AND relationship. If one array is specified in the value of a condition, then the elements inside the array are of OR relationship. Only restricted user access source (Referer and IP addresses) is currently supported. The list of currently supported operators and descriptions are given below.
Condition Operator | Description |
---|---|
StringEquals | It represents objects under /developers/design_info.doc in examplebucket bucket |
NotStringEquals | Unequal comparison of character string ignoring uppercase and lowercase |
StringLike | Comparison of character string ignoring uppercase and lowercase This value can contain multi-character wildcard * or single-character wildcard? |
StringNotLike | Comparison of mismatched character string ignoring uppercase and lowercase. This value can contain multi-character wildcard * or single-character wildcard? |
Condition Operator | Description |
---|---|
IpAddress | Specified IP address or range |
NotIpAddress | All IP addresses except the specified IP address or range |
Condition Operator | Description |
---|---|
Null | If it is null or has no value |
Example:
"Condition": { "IpAddress": {"aws:SourceIp": "54.240.143.0/24"}, "NotIpAddress": {"aws:SourceIp": "54.240.143.188/32"} }
"Condition":{ "StringLike":{"aws:Referer":["http://www.example.com/*","http://example2.com"]} }
{ "Statement": [{ "Sid": "allowReferer", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": [ "s3:PutObject", "s3:GetObject" ], "Resource": [ "arn:aws:s3:::yourbucket/*" ], "Condition": { "StringLike": { "aws:Referer": [ "www.abcxxx.com" ] } } }], "Id": "20190125114348155", "Version": "2012-10-17" }
{ "Version": "2012-10-17", "Id": "BucketId", "Statement": [{ "Sid": "OtherAccountAllow", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:root" ] }, "Action": ["s3:GetObject", "s3:PutObject"], "Resource": "arn:aws:s3:::testbucket/image.png" }] }