diff --git a/docs/obs/perms-cfg/ALL_META.TXT.json b/docs/obs/perms-cfg/ALL_META.TXT.json index f71fd6a44..dbde200c2 100644 --- a/docs/obs/perms-cfg/ALL_META.TXT.json +++ b/docs/obs/perms-cfg/ALL_META.TXT.json @@ -130,7 +130,7 @@ "node_id":"obs_40_0005.xml", "product_code":"obs", "code":"8", - "des":"An access control list (ACL) is a list of rules that specifies which users or systems are granted or denied access to a particular bucket or object.Bucket and object ACLs", + "des":"Access control lists (ACLs) allow resource owners to grant other accounts the access to resources. OBS ACLs define the read and write permissions that are attached to acc", "doc_type":"perms-cfg", "kw":"ACLs,Permission Control Methods,Permission Configuration Guide", "search_title":"", diff --git a/docs/obs/perms-cfg/CLASS.TXT.json b/docs/obs/perms-cfg/CLASS.TXT.json index 11db66e04..82e0effa8 100644 --- a/docs/obs/perms-cfg/CLASS.TXT.json +++ b/docs/obs/perms-cfg/CLASS.TXT.json @@ -63,7 +63,7 @@ "code":"7" }, { - "desc":"An access control list (ACL) is a list of rules that specifies which users or systems are granted or denied access to a particular bucket or object.Bucket and object ACLs", + "desc":"Access control lists (ACLs) allow resource owners to grant other accounts the access to resources. OBS ACLs define the read and write permissions that are attached to acc", "product_code":"obs", "title":"ACLs", "uri":"obs_40_0005.html", diff --git a/docs/obs/perms-cfg/obs_40_0001.html b/docs/obs/perms-cfg/obs_40_0001.html index 1e5557ba6..13f005282 100644 --- a/docs/obs/perms-cfg/obs_40_0001.html +++ b/docs/obs/perms-cfg/obs_40_0001.html @@ -15,7 +15,7 @@

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 permissions so that all users in the group automatically inherit the permissions of the user group.

+

IAM permissions are mainly used to manage IAM users' or user groups' access to cloud services and resources. You can grant IAM permissions to IAM users or user groups to allow or deny certain actions on specific cloud services and resources. After an IAM user is created, the administrator needs to add the user to a group. IAM can grant the user group required permissions so that all users in the group automatically inherit the permissions of the user group.

@@ -138,14 +138,12 @@ -

Relationships Between Bucket ACLs and Bucket Policies

Bucket ACLs control read and write permissions on buckets. Custom bucket policies allow a more refined control over more actions on buckets. In many cases, bucket policies can replace bucket ACLs to manage access to buckets more precisely. Relationship Between Bucket ACLs and Bucket Policies shows the mapping between bucket ACLs and bucket policies.

-

OBS Permission Control Principles

-

Which Permissions Apply When They Conflict?

In the OBS permission control elements, there are allow and deny effects, which indicate the permission to allow or deny an action.

+

Which Permissions Apply When They Conflict?

In the OBS permission control elements, there are allow and deny effects, which indicate the permission to allow or deny an action.

Following the least-privilege principle, the permission is defaulted to deny, and an explicit deny statement always takes precedence over an allow statement. For example, if 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, this user's 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 3 Authorization process
diff --git a/docs/obs/perms-cfg/obs_40_0003.html b/docs/obs/perms-cfg/obs_40_0003.html index 7c052b145..217149dec 100644 --- a/docs/obs/perms-cfg/obs_40_0003.html +++ b/docs/obs/perms-cfg/obs_40_0003.html @@ -5,7 +5,7 @@

IAM permissions apply to all OBS buckets and objects. To grant an IAM user the permission to operate OBS resources, you need to assign one or more OBS permission sets to the user group that the user belongs to.

OBS is a global service because it is available in all physical regions. If users in the global project are assigned IAM permissions, they do not need to switch regions to access OBS.

You can grant permissions to users by roles and policies.

- +

Due to data caching, a role and policy involving OBS actions will take effect 10 to 15 minutes after it is attached to a user or a user group.

IAM presets system permissions for each cloud service so that you can quickly configure basic permissions. Table 1 describes all system permissions of OBS.

diff --git a/docs/obs/perms-cfg/obs_40_0005.html b/docs/obs/perms-cfg/obs_40_0005.html index a721ef904..2eb892fb3 100644 --- a/docs/obs/perms-cfg/obs_40_0005.html +++ b/docs/obs/perms-cfg/obs_40_0005.html @@ -1,37 +1,76 @@

ACLs

-

An access control list (ACL) is a list of rules that specifies which users or systems are granted or denied access to a particular bucket or object.

-

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, OBS ACL has the following features:

-
  • An ACL applies to both the account and the users under the account.
  • If a bucket and its objects have the same owner, the ACL configured on the bucket also applies to the objects in the bucket by default.
  • An ACL can be created together with a bucket or its object. You can also configure one after the bucket or object is created.
-

ACLs are write and read permissions attached to accounts, and are not as fine-grained as bucket policies and IAM policies. It is recommended that you use IAM permissions and bucket policies for access control.

-

You can grant bucket access permissions to users or user groups listed in Table 1 by configuring an ACL.

+

Access control lists (ACLs) allow resource owners to grant other accounts the access to resources. OBS ACLs define the read and write permissions that are attached to accounts. The permissions granted to an account are also applied to its IAM users. ACLs are not as fine-grained as bucket policies or IAM policies. It is recommended that you use IAM permissions and bucket policies for access control.

+

By default, only the bucket creator (also the bucket owner) has full control over the bucket, and only the object uploader (also the object owner) has full control over the object. If resource owners want other accounts to access their resources, they can use ACLs to grant the read and write permissions.

+

Scenarios

You can configure an ACL to:

+
+
  • Let another account, rather than you (the object owner), have full control over your object. Suppose you have uploaded object a to a bucket of account B. By default, account B does not have the read and write permissions for your object a. In this case, you can set the object ACL to bucket-owner-full-control so that account B has full control over object a and can further manage it in the bucket in a unified manner.
  • Individually control access to a specific object. Suppose you have applied a bucket policy to a set of objects and you want to further control access to a single object in this set of objects. You can use the object ACL to achieve this.
+

Relationship Between Bucket ACLs and Object ACLs

Both buckets and objects have their own ACL. Table 1 shows the relationship between bucket ACLs and object ACLs.

-
Table 1 Users for whom you can create an ACL to grant bucket access permissions

Principal

+
+ + + + + + + + + + + + + + + + + + + + +
Table 1 Relationship between bucket ACLs and object ACLs

Dimension

+

Bucket ACL

+

Object ACL

+

Grantor

+

Bucket owner (the account that created the bucket)

+

A bucket owner has full control over the bucket by default. The read and write permissions for the bucket ACL are permanently available to the bucket owner, and cannot be modified. It is not recommended to modify a bucket owner's read and write permissions for the bucket.

+

Object owner (the account that uploaded the object, rather than the owner of the bucket that stores the object)

+

For example, if account A uploads object a to a bucket of account B, the owner of object a is account A.

+

The object owner has full control over the object by default. The read and write permissions for the object ACL are permanently available to the object owner, and cannot be modified.

+

Grantee

+
  • Other accounts
  • Anonymous users
  • Log delivery user groups
+
  • Other accounts
  • Anonymous users
+

Permissions that can be granted

+
  • Access to the bucket
  • Access to the bucket ACL
  • Whether the bucket ACL applies to its objects
+
  • Access to the object
  • Access to the object ACL
  • Whether the object inherits its bucket's ACL
+

Inheritance relationship between bucket ACLs and object ACLs

+

When an object ACL inherits a bucket ACL, the union of permissions from both ACLs is applied.

+
  • With the READ permission inherited, users granted the READ permission in both the bucket ACL and the object ACL can read the object. For example, if the bucket ACL grants anonymous users the read permission and the object ACL grants account A the read permission, the final effect is that both anonymous users and account A are allowed to read the object.
  • With the READ_ACP permission inherited, users granted the READ_ACP permission in both the bucket ACL and the object ACL can read the object ACL.
  • With the WRITE_ACP permission inherited, users granted the WRITE_ACP permission in both the bucket ACL and the object ACL can update the object ACL.
+
+
+ +

Grantee

You can configure an ACL to grant users or user groups listed in Table 2 access to buckets.

+
+ +
- - - - @@ -47,9 +86,9 @@
Table 2 Users who can be granted bucket access permissions in an ACL

Principal

Description

Specific users

+

Other accounts

ACLs can be used to grant accounts permissions to access buckets and objects. Once a specific account is granted such permissions, all IAM users under this account have the same permissions as this account.

-

If you want to grant different permissions to different IAM users, you can configure bucket policies.

-

Owner

-

The owner of a bucket is the account that created the bucket. The bucket owner has all permissions for the bucket 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 and is not necessarily 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 permissions for the bucket.

+

If you want to grant different permissions to different IAM users under other accounts, you can configure bucket policies.

+
NOTE:

Users must have both the ACL and IAM permissions to access resources across accounts. For details, see Which Permissions Apply When They Conflict?

Anonymous users

Visitors who have not registered.

-
NOTICE:

If the permissions to access a bucket or an object are granted to anonymous users, everyone can access the bucket or an object without authentication.

+
CAUTION:

If anonymous users are granted the access to a bucket or an object, anyone can access the bucket or the object without authentication.

-

Bucket ACL

Table 2 lists the permissions of a bucket ACL.

+

Permissions That Can Be Granted

Table 3 lists the permissions that can be configured in a bucket ACL.

-
Table 2 Bucket ACL permissions

Permission

+
@@ -91,149 +130,172 @@
Table 3 Bucket ACL permissions

Permission

Option

-

Table 3 lists the permissions of an object ACL.

+

Table 4 and Table 5 list the permissions that can be configured in an object ACL.

-
Table 3 Object ACL permissions

Permission

+
- - - - - - - - - - - -
Table 4 Object access permissions

Permission

Option

-

Description

+

Description

Access to object

+

Read

Read

-

A user with this permission can obtain the content and metadata of an object.

-

Access to ACL

-

Read

-

A user with this permission can obtain the object ACL.

-

The object owner has this permission permanently by default.

-

Write

-

A user with this permission can update the ACL of the object.

-

The object owner has this permission permanently by default.

+

A user with this permission can obtain the content and metadata of an object.

-

Every time you change the permissions for a bucket or an object in an ACL, it overwrites the existing permissions instead of adding permissions to the bucket or object.

-
- -

Application Scenarios of Bucket ACLs

You can configure bucket ACLs to:

-
  • Grant an account the read and write permissions to a bucket, so that this account can add the bucket as an external one and access objects in the bucket. For example, if you grant an account the read and write permissions to a bucket, the account can access the bucket by adding it as an external bucket through OBS Browser+ or by using APIs.
  • Grant the log delivery user group the write permissions to a bucket that stores access logs.
-
-

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 control access to a single object in the set of objects for which a bucket policy has been configured, use the object ACL.
  • Access an object through a URL. 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, 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.

-
Table 4 Predefined permissions in OBS

Permission

+
- - - - - - - - - - - - - - - - -
Table 5 Object ACL access permissions

Permission

Description

+

Description

private

+

Read

A bucket or an object can be accessed only by its owner.

+

A user with this permission can read the object ACL.

public-read

+

Write

If this permission is set for a bucket, everyone can obtain its object list, multipart tasks, and metadata.

-

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 its object list, multipart uploads, and metadata.
  • Upload, delete objects.
  • Initiate, cancel multipart uploads, upload, assemble, and copy parts.
-

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 its object list, multipart tasks, metadata, 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 its object list, multipart uploads, and metadata.
  • Upload, delete objects, and obtain content and metadata of objects in the bucket.
  • Initiate, cancel multipart uploads, upload, assemble, and copy parts.
-

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 permission to the bucket owner, the bucket owner can have full control over your object.

-

+

A user with this permission can update the object ACL.

-

By default, the permission is private.

-
-

You can also use the following header fields to set permissions when creating a bucket or uploading an object.

+ +

How Do I Configure an ACL?

You can use the predefined bucket or object ACLs or customize an ACL.

+
+

Using Predefined ACLs

OBS provides six types of predefined ACLs, as described in Table 6. A predefined ACL is applied to all users.

-
- + + + @@ -158,415 +197,9 @@
  • Include: The bucket policy applies to specified actions.
  • Exclude: The bucket policy applies to actions except the specified ones.

Bucket Actions

- -
Table 5 Header fields for setting bucket or object ACLs

Header

+
- - - - - - - - - - - - - - - -
Table 6 OBS-predefined ACLs

Predefined ACL

Description

+

Description

x-obs-grant-read

+

private

Used to grant the READ permission to all users in a specific account.

+

A bucket or an object can only be accessed by its owner.

+

By default, the ACL is set to private.

x-obs-grant-write

+

public-read

Used to grant the WRITE permission to all users in a specific account.

+

If this permission is set for a bucket, anyone can obtain its object list, multipart tasks, and metadata.

+

If this permission is set for an object, anyone can obtain the content and metadata of the object.

x-obs-grant-read-acp

+

public-read-write

Used to grant the READ_ACP permission to all users in a specific account.

+

If this permission is set for a bucket, anyone can obtain its object list, multipart upload tasks, and metadata, and can upload, delete objects, initiate multipart uploads, upload, assemble, and copy parts, and cancel multipart uploads.

+

If this permission is set for an object, anyone can obtain the content and metadata of the object. This permission works the same as public-read.

x-obs-grant-write-acp

+

public-read-delivered

Used to grant the WRITE_ACP permission to all users in a specific account.

+

If this permission is set for a bucket, anyone can obtain its object list, multipart upload tasks, and metadata. Compared with public-read, this permission also allows access to the content and metadata of the objects in the bucket.

+

This permission does not apply to objects.

x-obs-grant-full-control

+

public-read-write-delivered

Used to grant the FULL_CONTROL permission to all users in a specific account.

+

If this permission is set for a bucket, anyone can obtain its object list, multipart upload tasks, and metadata, and can upload, delete objects, initiate multipart uploads, upload, assemble, and copy parts, and cancel multipart uploads. Compared with public-read-write, this permission also allows access to the content and metadata of the objects in the bucket.

+

This permission does not apply to objects.

x-obs-grant-read-delivered

+

bucket-owner-full-control

Used to grant the READ permission for buckets and their objects 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 their objects to all users in a specific account, and objects inherit the permissions of their bucket.

-

This permission does not apply to objects.

+

Setting this permission for an object will enable the bucket owner to have 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 access to your object. After you grant the bucket-owner-full-control permission to the bucket owner, the bucket owner can have full control over your object.

+

+

Using OBS Console to Configure Predefined ACLs

+

Using APIs to Configure Predefined ACLs

+

You can use the x-obs-acl header to configure the bucket or object ACL when creating a bucket or uploading an object. For details, see Creating a Bucket and Uploading an Object. You can also configure the bucket or object ACL after the bucket is created or the object is uploaded. For details, see Configuring a Bucket ACL and Configuring an Object ACL.

+ +

Customizing an ACL

You can customize ACLs to grant permissions to specified accounts or anonymous users. Table 7 lists the permissions that can be configured in bucket or object ACLs.

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Table 7 Permissions that can be configured in bucket or object ACLs

Permission

+

When Granted for a Bucket

+

When Granted for an Object

+

API Header

+

READ

+

A user with this permission can obtain the list of objects in the bucket and the metadata of the bucket.

+

A user with this permission can obtain the content and metadata of the object.

+

x-obs-grant-read

+

WRITE

+

A user with this permission can upload objects to the bucket, and can delete and overwrite existing objects in the bucket.

+

Not supported

+

x-obs-grant-write

+

READ_ACP

+

A user with this permission can read the bucket ACL.

+

A user with this permission can read the object ACL.

+

x-obs-grant-read-acp

+

WRITE_ACP

+

A user with this permission can update the bucket ACL.

+

A user with this permission can update the object ACL.

+

x-obs-grant-write-acp

+

FULL_CONTROL

+

A user with this permission has the READ, WRITE, READ_ACP, and WRITE_ACP permissions.

+

A user with this permission has the READ, READ_ACP, and WRITE_ACP permissions for the object.

+

x-obs-grant-full-control

+
+
+

OBS allows you to customize an object ACL to inherit the bucket ACL. You can use the x-obs-grant-read-delivered header to configure a bucket ACL so that grantees can obtain the list of objects in the bucket and the metadata of the bucket, and also have the READ permission for objects in the bucket. Using the x-obs-grant-full-control-delivered header in a bucket ACL to grant the grantee the READ, WRITE, READ_ACP, and WRITE_ACP permissions for the bucket and also the READ, READ_ACP, and WRITE_ACP permissions for the objects in the bucket.

+

+

Using OBS Console to Customize an ACL

+

Using APIs to Customize an ACL

+
diff --git a/docs/obs/perms-cfg/obs_40_0007.html b/docs/obs/perms-cfg/obs_40_0007.html index bef08efcc..38e09bf57 100644 --- a/docs/obs/perms-cfg/obs_40_0007.html +++ b/docs/obs/perms-cfg/obs_40_0007.html @@ -3,7 +3,7 @@

Accessing OBS Using Permanent Access Keys

OBS REST APIs support authenticated requests and anonymous requests. Anonymous requests are typically used for public access, such as accessing hosted static websites. In most cases, authenticated requests are required for accessing OBS resources. An authenticated request contains a signature value that is calculated based on the requester's access keys (AK and SK) and the specific information carried in the request body. You only need to prepare the access keys for the SDK. The SDK will then automatically calculate the signature for you. However, if a client uses REST APIs to develop a program to access OBS, the client needs to calculate the signature based on the signature algorithm defined by OBS and add the signature to the request.

Users can create permanent access keys (a pair of AK and SK) on the My Credentials page.

-
  • AK: a unique ID of the secret access key (SK). An AK is used together with an SK to encrypt and sign a request.
  • SK: a secret access key used together with its AK to verify a request sender and prevent the request from being tampered with.
+
  • AK: a unique ID of the secret access key (SK). An AK is used together with an SK to encrypt and sign a request. For details, see User Signature Authentication.
  • SK: a secret access key used together with its AK to verify a request sender and prevent the request from being tampered with.

An AK can also identify an IAM user. OBS identifies an IAM user by their AK and SK, and then checks whether they have the permissions to access the resources they are requesting.

For details about how to obtain the permanent access keys, see Where Can I Obtain Access Keys (AK and SK)?

diff --git a/docs/obs/perms-cfg/obs_40_0009.html b/docs/obs/perms-cfg/obs_40_0009.html index ae58834d8..a61115dbe 100644 --- a/docs/obs/perms-cfg/obs_40_0009.html +++ b/docs/obs/perms-cfg/obs_40_0009.html @@ -6,7 +6,7 @@

Sharing a file

All URLs generated during file sharing are temporary and remain valid for a specified period of time.

A temporary URL uses V4 temporarily authorized requests. The following is an example:

-
https://oss.regionid.example.region.com/bucketname/objectname?X-Amz-Algorithm=xxx&X-Amz-Credential=xxx&X-Amz-Date=xxx&X-Amz-Expires=900&X-Amz-Signature=xxx&X-Amz-SignedHeaders=xxx&response-content-disposition=xxx
+
https://bucketname.oss.regionid.example.region.com/objectname?X-Amz-Algorithm=xxx&X-Amz-Credential=xxx&X-Amz-Date=xxx&X-Amz-Expires=900&X-Amz-Signature=xxx&X-Amz-SignedHeaders=xxx&response-content-disposition=xxx

For details about the temporary authentication and parameters, see V4 Temporarily Authorized Request in the Object Storage Service API Reference. A temporary URL also contains the response-content-disposition parameter that defines whether an object is to be downloaded or previewed in a browser. The browser obtains the value of response-content-disposition based on the Content-Type of the shared object.

After you share an object by choosing More > Copy Object URL on OBS Console, the system will generate a URL that contains the temporary authentication information, valid for 900 seconds since its generation by default. Each time you click Copy Object URL, OBS will obtain the authentication information again to generate a new sharing URL whose validity period is reset.

diff --git a/docs/obs/perms-cfg/obs_40_0010.html b/docs/obs/perms-cfg/obs_40_0010.html index 99deafa4a..a4c8206c0 100644 --- a/docs/obs/perms-cfg/obs_40_0010.html +++ b/docs/obs/perms-cfg/obs_40_0010.html @@ -2,7 +2,7 @@

Accessing OBS Using an IAM Agency

The IAM agency is a function of Identity and Access Management (IAM). In scenarios such as CDN private bucket retrieval and cross-region replication, IAM agencies are required to grant other accounts or cloud services the permissions to access and to securely and efficiently manage OBS resources.

-

If you want to synchronously replicate encrypted objects, you need to select or create an agency to authorize OBS to access Key Management Service (KMS) when creating a cross-region replication rule.

+

For example, when creating a cross-region replication rule, if you want to synchronously replicate encrypted objects, you need to select or create an agency to authorize OBS to access Key Management Service (KMS).

For details about IAM agencies, see Identity and Access Management User Guide.

diff --git a/docs/obs/perms-cfg/obs_40_0039.html b/docs/obs/perms-cfg/obs_40_0039.html index 0e5ad1025..9da24f967 100644 --- a/docs/obs/perms-cfg/obs_40_0039.html +++ b/docs/obs/perms-cfg/obs_40_0039.html @@ -8,7 +8,14 @@

2025-04-07

+

2025-08-20

+

This issue is the fifth official release.

+

This issue incorporates the following change:

+

Updated the description about the domain name structure in Accessing OBS Using a Temporary URL.

+

2025-04-07

This issue is the fourth official release.

This issue incorporates the following changes:

diff --git a/docs/obs/perms-cfg/obs_40_0041.html b/docs/obs/perms-cfg/obs_40_0041.html index 759a6afb4..b216a8be4 100644 --- a/docs/obs/perms-cfg/obs_40_0041.html +++ b/docs/obs/perms-cfg/obs_40_0041.html @@ -60,6 +60,45 @@

NotPrincipal

Users that the statement does not apply to. Its value has the same format as Principal.

+

The following gives an example that denies all operations performed by users except the specified IAM user.

+

domain_id indicates the account ID, and user_id indicates the IAM user ID.

+
 1
+ 2
+ 3
+ 4
+ 5
+ 6
+ 7
+ 8
+ 9
+10
+11
+12
+13
+14
+15
+16
+17
+18
{
+    "Statement": [
+        {
+            "Effect": "Deny", 
+            "Action": ["*"], 
+            "Resource": [
+                "examplebucket/*", 
+                "examplebucket"
+            ], 
+            "NotPrincipal": {
+                "ID": [
+                    "domain/domain_id:user/user_id", 
+                    "domain/domain_id:root"
+                ]
+            }
+        }
+     ]
+}
+
+

Optional. Select either NotPrincipal or Principal.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 2 Description of bucket-related actions

Type

-

Value

-

Description

-

General

-

*

-

Indicates all actions on a bucket.

-

Get*

-

Indicates all GET actions on a bucket.

-

Put*

-

Indicates all PUT actions on a bucket.

-

List*

-

Indicates all LIST actions on a bucket.

-

Bucket

-

Operations on buckets

-

ListBucket

-

Lists objects in a bucket, and obtains the bucket metadata.

-

DeleteBucket

-

Deletes a bucket.

-

GetBucketLocation

-

Gets the location of a bucket.

-

GetBucketStorage

-

Obtains bucket storage information.

-

Bucket policies

-

GetBucketPolicy

-

Gets a bucket policy.

-

PutBucketPolicy

-

Configures a bucket policy.

-

DeleteBucketPolicy

-

Deletes a bucket policy.

-

Bucket ACL

-

GetBucketAcl

-

Gets the ACL information of a bucket.

-

PutBucketAcl

-

Configures ACL for a bucket.

-

Bucket logs

-

GetBucketLogging

-

Gets the logs of a bucket.

-

PutBucketLogging

-

Configures logging for a bucket.

-

Lifecycle rules

-

GetLifecycleConfiguration

-

Obtains the lifecycle rules of a bucket.

-

PutLifecycleConfiguration

-

Configures a lifecycle rule for a bucket.

-

Static website hosting

-

GetBucketWebsite

-

Obtains the static website configuration of a bucket.

-

PutBucketWebsite

-

Configures static website hosting for a bucket.

-

DeleteBucketWebsite

-

Cancels static website hosting for a bucket.

-

Bucket versioning

-

GetBucketVersioning

-

Gets the versioning information of a bucket.

-

PutBucketVersioning

-

Configures versioning for a bucket.

-

ListBucketVersions

-

Lists object versions in a bucket.

-

Bucket tags

-

GetBucketTagging

-

Gets bucket tags.

-

PutBucketTagging

-

Configures tags for a bucket.

-

DeleteBucketTagging

-

Deletes bucket tags.

-

CORS rules

-

GetBucketCORS

-

Gets the CORS configuration of a bucket.

-

PutBucketCORS

-

Configures CORS for a bucket.

-

Message notifications

-

GetBucketNotification

-

Gets event notifications of a bucket.

-

PutBucketNotification

-

Configures event notifications for a bucket.

-

Bucket storage class

-

GetBucketStoragePolicy

-

Gets the default storage class of a bucket.

-

PutBucketStoragePolicy

-

Configures the default storage class for a bucket.

-

Bucket storage quota

-

GetBucketQuota

-

Gets storage quotas of a bucket.

-

PutBucketQuota

-

Configures storage quotas for a bucket.

-

User-defined domain names

-

GetBucketCustomDomainConfiguration

-

Gets the user-defined domain name of a bucket.

-

PutBucketCustomDomainConfiguration

-

Binds a user-defined domain name to a bucket.

-

DeleteBucketCustomDomainConfiguration

-

Unbinds a user-defined domain name from a bucket.

-

Bucket encryption

-

GetEncryptionConfiguration

-

Obtains the server-side encryption configuration of a bucket.

-

PutEncryptionConfiguration

-

Configures server-side encryption for a bucket.

-

Default bucket retention policy

-

GetBucketObjectLockConfiguration

-

Obtains the default retention settings of a bucket.

-

PutBucketObjectLockConfiguration

-

Configures a default retention policy for a bucket.

-

Bucket inventories

-

GetBucketInventoryConfiguration

-

Gets the inventory configuration of a bucket.

-

PutBucketInventoryConfiguration

-

Configures inventories for a bucket.

-

DeleteBucketInventoryConfiguration

-

Deletes the inventory configuration of a bucket.

-

Other

-

GetReplicationConfiguration

-

Gets the cross-region replication configuration of a bucket.

-

PutReplicationConfiguration

-

Configures cross-region replication for a bucket.

-

DeleteReplicationConfiguration

-

Deletes the cross-region replication configuration of a bucket.

-

ListBucketMultipartUploads

-

Lists multipart upload tasks.

-
-
+

For details, see Bucket Actions.

Object Actions

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 3 Description of object-related actions

Type

-

Value

-

Description

-

General

-

*

-

Indicates all actions on an object.

-

Get*

-

Indicates all GET actions on an object.

-

Put*

-

Indicates all PUT actions on an object.

-

List*

-

Indicates all LIST actions on an object.

-

Object

-

Operations on objects

-

GetObject

-

Gets the content and metadata of an object.

-

PutObject

-

Performs PUT upload, POST upload, multipart upload, initialization of uploaded parts, and assembling of parts.

-

RestoreObject

-

Restores Cold objects.

-

DeleteObject

-

Deletes an object.

-

Object ACL

-

GetObjectAcl

-

Gets the ACL information of an object.

-

PutObjectAcl

-

Configures ACL for an object.

-

Versioning

-

GetObjectVersion

-

Gets the content and metadata of a specified object version.

-

DeleteObjectVersion

-

Deletes a specified object version.

-

Object version ACL

-

GetObjectVersionAcl

-

Gets the ACL information of a specified object version.

-

PutObjectVersionAcl

-

Configures ACL for a specified object version.

-

Object retention policy

-

PutObjectRetention

-

Configures a retention policy for an object.

-

Other

-

AbortMultipartUpload

-

Cancels a multipart upload.

-

ListMultipartUploadParts

-

Lists uploaded parts.

-

ModifyObjectMetadata

-

Modifies object metadata.

-
-
+

For details, see Object Actions.

Resource/NotResource

The resources supported by OBS are as follows:

  • bucketname: The Action drop-down list box lists all actions allowed on a bucket. To allow an action on a bucket, set Resource to the bucket name.
  • bucketname/objectname: The Action drop-down list box lists all actions allowed on an object. To allow an action on an object in a bucket, set Resource to bucketname/objectname. You can use a wildcard for objectname to allow an action on all objects in the bucket. For example, if you want to allow an action on all objects in a directory of a bucket, set Resource to "bucketname/directory/*". If you have permissions on all the objects in a bucket, set Resource to "bucketname/*". If you want to allow an action on both a bucket and its objects, set Resource to ["examplebucket/*","examplebucket"].
@@ -632,355 +265,433 @@ } }

+

Condition Operators

-