ACLs
An ACL is a list that defines grantees and their granted permissions.
Bucket and object ACLs are attached to accounts. By default, an ACL is created when a bucket or object is created, authorizing the owner the full control over the bucket or object.
To implement simple and practical authorization for users, the OBS ACL has the following features:
- The ACL takes effect for both the account and the users under the account.
- When the owner of a bucket is the same as the owner of an object, the ACL configured on the bucket takes effect on the bucket and objects in the bucket by default.
- An ACL can be carried when a bucket is created, or an ACL can be configured after a bucket is created. An object can carry an ACL when it is uploaded. You can also configure the ACL after the object is uploaded successfully.
ACLs are write and read control rules attached to accounts, whose permission granularity is not as fine as bucket policies and IAM policies. Generally, it is recommended that you use IAM permissions and bucket policies for access control.
Table 1 lists users to whom you can grant bucket access permissions by configuring an ACL.
Principal |
Description |
---|---|
Specific User |
ACLs can be used to grant accounts with bucket/object access permissions. Once a specific account is granted with certain bucket/object access permissions, all IAM users who have OBS resource permissions under this account can have the same access permissions to operate the bucket or object. You can configure bucket policies to grant different permissions to different IAM users. |
Owner |
The owner of a bucket is the account that created the bucket. The bucket owner has all bucket access permissions by default. The read and write permissions to the bucket ACL are permanently available to the bucket owner, and cannot be modified. An object owner is the account that uploads the object, but may not be the owner of the bucket that stores the object. The object owner has all control over the object by default. The read and write permissions to the object ACL are permanently available to the object owner, and cannot be modified.
NOTICE:
Do not modify the bucket owner's read and write access permissions for the bucket. |
Anonymous users |
Visitors who have not registered. If the permissions to access a bucket or an object are granted to anonymous users, everyone can access the object or bucket without identity authentication.
NOTICE:
If the permissions to access a bucket or an object are granted to anonymous users, everyone can access the object or bucket without identity authentication. |
Log delivery user groups
NOTE:
Only the bucket ACL supports authorizing permissions to the log delivery user. |
A log delivery user group only delivers access logs of buckets and objects to the configured target bucket. OBS does not create or upload any file to a bucket automatically. Therefore, if you want to record access logs for buckets, you need to grant the permission to a log delivery user group who will deliver the access logs to your specified target bucket. This user group is only used to record internal logs of OBS.
NOTICE:
After logging is enabled, the log delivery user will be automatically granted the permission to read the bucket ACL and write the bucket where logs are saved. If you manually disable such permissions, bucket logging fails. |
Bucket ACL
Table 2 lists the access permissions of a bucket ACL.
Permission Related Concepts |
Option |
Description |
---|---|---|
Access to Bucket |
Read |
A grantee with the read access to a bucket can obtain the list of objects in the bucket and the metadata of the bucket. |
Read |
A grantee with this permission can obtain the object content and metadata. |
|
Write |
A grantee with the write access to a bucket can upload, overwrite, and delete any object in the bucket. |
|
Access to ACL |
Read |
A grantee with the read access to a bucket ACL can obtain the ACL of the bucket. The bucket owner has this permission permanently by default. |
Write |
A grantee with the write access to a bucket ACL can update the ACL of the bucket. The bucket owner has this permission permanently by default. |
Table 3 lists the access permissions of an object ACL.
Permission Related Concepts |
Option |
Description |
---|---|---|
Access to Object |
Read |
A grantee with the read access to an object can obtain the content and the metadata of the object. |
Access to ACL |
Read |
A grantee with the read access to an object ACL can obtain the ACL of the object. The object owner has this permission permanently by default. |
Write |
A grantee with the write access to an object ACL can update the ACL of the object. The object owner has this permission permanently by default. |
Every time you change the bucket or object access permission setting in an ACL, it overwrites the existing setting instead of adding a new access permission to the bucket or object.
Application Scenarios of Bucket ACLs
You can configure bucket ACLs to:
- Grant an account the read and write access to a bucket, so that data in the bucket can be shared or external buckets can be added. For example, after account A grants account B the read and write access to a bucket, account B can access the bucket by adding an external bucket through OBS Browser+ or using APIs.
- Grant the log delivery user group with the write access to the target bucket, so that access logs can be delivered to the target bucket.
Application Scenarios of Object ACLs
You can configure object ACLs to:
- Control access to objects. A bucket policy can control access to a single object or a set of objects. If you want to further separately control access to a single object in the set of objects for which a bucket policy has been configured, the object ACL is recommended.
- Access an object through a URL. Generally, if you want to grant anonymous users the permission to read an object through a URL, use the object ACL.
Configuring an ACL Using Header Fields
Access Control Policies
You can set an access control policy in a header when creating a bucket or uploading an object (for details about the examples, see Creating a Bucket and Uploading Objects - PUT). Only the access control policies predefined in OBS are available. The x-obs-acl is special, which can be configured with six types of permissions. No matter what type of permissions is configured, the owner has full control permission for the buckets or objects. The following table lists the predefined policies.
Policy |
Description |
---|---|
private |
Indicates that a bucket or object can be accessed only by its owner. |
public-read |
If this permission is set for a bucket, everyone can obtain the object list, multipart tasks, bucket metadata, and multiple object versions. If this permission is set for an object, everyone can obtain the content and metadata of the object. |
public-read-write |
If this permission is configured for a bucket, everyone can obtain the object list, multipart uploads, bucket metadata, and object versions, and can upload or delete objects, initiate multipart uploads, upload parts, assemble parts, copy parts, and cancel multipart uploads. If this permission is set for an object, everyone can obtain the content and metadata of the object. |
public-read-delivered |
If this permission is set for a bucket, everyone can obtain the object list, multipart tasks, bucket metadata, and multiple object versions, and obtain the content and metadata of the objects in the bucket. This permission does not apply to objects. |
public-read-write-delivered |
If this permission is configured for a bucket, everyone can obtain the object list, multipart uploads, bucket metadata, and object versions, and can upload or delete objects, initiate multipart uploads, upload parts, assemble parts, copy parts, and cancel multipart uploads. Users can also obtain content and metadata of objects in the bucket. This permission does not apply to objects. |
bucket-owner-full-control |
If this permission is configured for an object, the bucket and object owners have the full control over the object. By default, if you upload an object to a bucket of any other user, the bucket owner does not have the permissions on your object. After you grant this policy to the bucket owner, the bucket owner can have full control over your object. |
By default, the access control policy is private.
You can also use the following header fields to set access control policies when creating a bucket or uploading an object.
Header |
Description |
---|---|
x-obs-grant-read |
Used to grant the READ permission to all users in a specific account. |
x-obs-grant-write |
Used to grant the WRITE permission to all users in a specific account. |
x-obs-grant-read-acp |
Used to grant the READ_ACP permission to all users in a specific account. |
x-obs-grant-write-acp |
Used to grant the WRITE_ACP permission to all users in a specific account. |
x-obs-grant-full-control |
Used to grant the FULL_CONTROL permission to all users in a specific account. |
x-obs-grant-read-delivered |
Used to grant the READ permission for buckets and objects in the buckets to all users in a specific account, and objects inherit the permissions of their bucket. This permission does not apply to objects. |
x-obs-grant-full-control-delivered |
Used to grant the FULL_CONTROL permission for buckets and objects in the buckets to all users in a specific account, and objects inherit the permissions of their bucket. This permission does not apply to objects. |
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot