By default, OBS resources (buckets and objects) are private. Only resource owners can access their OBS resources. Without authorization, other users cannot access OBS. OBS permission control refers to granting permissions to other accounts or IAM users by editing access policies. For example, if you have a bucket, you can authorize another IAM user to upload objects to your bucket. You can also open buckets to non-public cloud users, so that anyone can access your buckets as public resources over the Internet. OBS offers different methods to help resource owners grant resource permissions to others as required, keeping data secure.
OBS provides multiple permission control mechanisms, including IAM permissions, bucket policies, object ACLs, and bucket ACLs. Table 1 describes the mechanisms and application scenarios.
Method |
Description |
Scenario |
---|---|---|
IAM permissions |
IAM permissions define the actions that can be performed on your cloud resources. In other words, IAM permissions specify what actions are allowed or denied. After an IAM user is created, the administrator needs to add the user to a group. IAM can grant the user group required OBS access permissions, and then all users in the group automatically inherit the permissions of the user group. |
|
Bucket policies |
A bucket policy is attached to a bucket and objects in the bucket. Bucket owners can use bucket policies to grant IAM users or other accounts the permissions to operate buckets and objects in the buckets. ACLs of buckets and objects supplement bucket policies, and in many cases, bucket policies replace ACLs. |
|
Object ACLs |
Controls access to objects for accounts or user groups. Object owners can configure the object access control list (ACL) to grant basic read and write permissions to specified accounts or user groups. NOTE:
|
|
Bucket ACLs |
Controls access to buckets for accounts or user groups. Bucket owners can configure the bucket ACL to grant basic read and write permissions to specified accounts or user groups. NOTE:
|
|
OBS provides multiple permission control mechanisms, including time-limited access to objects, object ACLs, bucket ACLs, and bucket policies. Some service-level permissions (for example, creating a bucket and listing all buckets) cannot be configured through OBS and can only be configured on IAM. OBS permissions apply only to resources (buckets and objects). To grant both OBS service-level and resource-level permissions, you must use IAM permissions or both IAM and OBS permissions.
The following factors determine the authorization result:
For details about elements, see Bucket Policy Parameters.
Table 2 describes elements in different permission control mechanisms.
Method |
Principal |
Supported Effect |
Authorized Resource |
Authorized Action |
Condition Configuration |
---|---|---|---|---|---|
IAM Permissions |
IAM user |
|
All or specified OBS resources |
All permissions to access OBS |
Supported |
Bucket Policy |
|
|
Specified bucket and resources in the bucket |
All permissions to access OBS |
Supported |
Object ACL |
|
Allow |
Specified object |
|
Not supported |
Bucket ACL |
|
Allow |
Specified bucket |
|
Not supported |
Based on the advantages and disadvantages of the three elements, you are advised to preferentially use IAM permissions and bucket policies.
Identify the problem you are most concerned with:
You can search for an IAM user and check the permissions of the user group to which the user belongs to know what the user can do.
You can query the bucket and check the bucket policy to know who can access the bucket.
It is better for you to use the same method for access control, because as the number of IAM permissions and bucket policies increase, access maintenance will become increasingly difficult.
When to Select an ACL?
IAM permissions and bucket policies have granted access permissions to an object set, but you want to grant access permissions to a single object.
When uploading an object, you can use the ACL header to specify the read and write permissions of the object.
Bucket ACLs are used to control basic read and write access to buckets. Custom settings of bucket policies support more actions that can be performed on buckets. Bucket ACLs supplement bucket policies. In many cases, bucket policies can replace bucket ACLs to manage access to buckets. Relationship Between Bucket Policies and Bucket ACLs shows the mapping between bucket ACL access permissions and bucket policy actions.
Never grant IAM users more than the minimum level of access needed to complete a task. For example, if an IAM user only needs to upload and download objects to a directory, you do not need to assign the user the read and write permissions for the entire bucket.
Management of resources or of permissions can be assigned to different IAM users. For example, you can let one IAM user assign permissions, and let other IAM users manage OBS resources.
To enhance the security of the resources in a bucket, specific conditions can be configured to control when a permission is applied. For example, a bucket policy with conditions contained can be configured for OBS to accept requests only from a specific IP address.
In the OBS permission control elements, there are allow and deny effects, which indicate the permission to allow or deny an operation.
Based on the least-privilege principle, decisions default to deny, and an explicit deny statement always takes precedence over an allow statement. For example, IAM permissions grant a user access to an object, a bucket policy denies the user's access to that object, and there is no ACL. Then access will be denied.
If no method specifies an allow statement, then the request will be denied by default. Only if no method specifies a deny statement and one or more methods specify an allow statement, will the request be allowed. For example, if a bucket has multiple bucket policies with allow statements, adding such a new bucket policy applies the allowed permissions to the bucket, but adding a new bucket policy with a deny statement will make the permissions work differently. The deny statement will take precedence over allow statements, even if the denied permissions are allowed in other bucket policies.
Figure 4 describes how bucket policies, IAM permissions, and ACLs work (allow or deny) when you grant the IAM users of your account the access to OBS buckets and resources in the buckets. ACLs are applied to accounts and do not control IAM users' read and write permissions for the buckets and the sources in the buckets under their account.
Figure 5 describes how bucket policies, IAM permissions, and ACLs work (allow or deny) when you grant any other account and the IAM users of this account the access to OBS buckets and resources in the buckets.