Using IAM Roles or Policies to Grant Access to OBS

You can use Identity and Access Management (IAM) to control access to your OBS resources. IAM provides two authorization models: role/policy-based authorization and identity policy-based authorization. For details about the differences between these two models, see Permissions and Supported Actions. This section describes role/policy-based authorization. With IAM role/policy-based authorization, you can:

Create IAM users for personnel based on your enterprise's organizational structure. Each IAM user has their own identity credentials for accessing OBS resources.
Grant users only the permissions required to perform a given task based on their job responsibilities.
Entrust a HUAWEI ID or a cloud service to perform professional and efficient O&M on your OBS resources.

If your Huawei Cloud account meets your permissions requirements, you can skip this section.

Figure 1 shows the process of role/policy-based authorization.

Prerequisites

You have learned which OBS permissions can be assigned to user groups. To grant permissions for services other than OBS, learn about all system-defined permissions supported by IAM.

Process Flow

Figure 1 Process of granting OBS permissions using role/policy-based authorization
Click to enlarge

On the IAM console, create a user group and grant it permissions (OBS ReadOnlyAccess as an example).
Create a user group on the IAM console and assign the OBS ReadOnlyAccess permission to it.
Create an IAM user and add it to the created user group.
Create a user on the IAM console and add the user to the group created in 1.
Log in as the IAM user and verify permissions.
In the authorized region, perform the following operations:
- Choose Service List > Object Storage Service. Then click Create Bucket on OBS Console. If a message appears indicating that you have insufficient permissions to perform the operation, the OBS ReadOnlyAccess policy is in effect.
- Choose another service from Service List. If a message appears indicating that you have insufficient permissions to access the service, the OBS ReadOnlyAccess policy is in effect.

Example Custom Policies

You can create custom policies to supplement the system-defined policies of OBS. For details about actions supported in custom policies, see Bucket Actions.

To create a custom policy, choose either visual editor or JSON.

Visual editor: Select cloud services, actions, resources, and request conditions. This does not require knowledge of policy syntax.
JSON: Create a JSON policy or edit an existing one.

For details, see Creating a Custom Policy. The following lists examples of common OBS custom policies.

Example 1: Grant users all OBS permissions.

This policy allows an authorized user to perform any operation on OBS.

{
    "Version": "1.1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "obs:*:*"
            ]
        }
    ]
}

Example 2: Grant users all permissions for OBS Console.
This policy allows users to perform all operations on OBS Console.

When logging in to OBS Console, users may need to access resources of other services, such as CTS audit information, CDN acceleration domain names, and KMS keys. For this reason, in addition to the OBS permissions granted in example 1, the access permissions for other services need to be granted. CDN is global, while CTS and KMS are regional. You need to configure the Tenant Guest permissions for the global project and regional projects based on the services and regions that you use. The Tenant Guest permissions have the read-only permissions for all services except IAM.
```
{
    "Version": "1.1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "obs:*:*"
            ]
        }
    ]
}
```

Example 3: Grant users the permissions to list and download all objects in a bucket.

This policy allows an authorized user to list and download all objects in bucket obs-example.

{
    "Version": "1.1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "obs:object:GetObject",
                "obs:object:GetObjectVersion",
                "obs:bucket:ListBucket"
            ],
            "Resource": [
                "obs:*:*:object:obs-example/*",
                "obs:*:*:bucket:obs-example"
            ]
        }
    ]
}

Example 4: Grant users the permissions to list objects and download objects from a specified directory in a bucket.

This policy allows an authorized user to download objects only in the my-project/ directory in bucket obs-example. Objects in any other directory in the bucket can be listed but cannot be downloaded.

{
    "Version": "1.1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "obs:object:GetObject",
                "obs:object:GetObjectVersion",
                "obs:bucket:ListBucket"
            ],
            "Resource": [
                "obs:*:*:object:obs-example/my-project/*",
                "obs:*:*:bucket:obs-example"
            ]
        }
    ]
}

Example 5: Grant users the read/write permissions for a specified directory in a bucket.

This policy allows an authorized user to list, upload, download, and delete objects in the my-project directory in bucket obs-example.

{
    "Version": "1.1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "obs:object:GetObject",
                "obs:object:ListMultipartUploadParts",
                "obs:bucket:ListBucket",
                "obs:object:DeleteObject",
                "obs:object:PutObject"
            ],
            "Resource": [
                "obs:*:*:object:obs-example/my-project/*",
                "obs:*:*:bucket:obs-example"
            ]
        }
    ]
}

Example 6: Grant users all permissions for a bucket.

This policy allows an authorized user to perform all operations on bucket obs-example.

{
    "Version": "1.1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "obs:*:*"
            ],
            "Resource": [
                "obs:*:*:bucket:obs-example",
                "obs:*:*:object:obs-example/*"
            ]
        }
    ]
}

Example 7: Grant users the permission to deny object upload.
A policy with only "Deny" permissions must be used together with other policies. If the permissions granted to an IAM user contain both "Allow" and "Deny", the "Deny" permissions take precedence over the "Allow" permissions.

Assume that you want to grant the permissions of the OBS OperateAccess policy to a user but want to prevent the user from uploading objects. You can create a custom policy for denying object upload, and attach this policy together with the OBS OperateAccess policy to the user. As an explicit deny in any policy overrides any allows, the user can perform all operations allowed by OBS OperateAccess except uploading objects. The following gives an example policy that denies object upload.
```
{
    "Version": "1.1",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "obs:object:PutObject"
            ]
        }
    ]
}
```

OBS Resources

A resource is an object that exists within a service. OBS resources include buckets and objects. You can select these resources by specifying their paths.

**Table 1** OBS resources and their paths
Resource	Path
Bucket	[Format] *obs:::bucket:*Bucket name [Notes] IAM automatically generates the prefix *obs:::bucket:* for bucket resource paths. By adding Bucket name to the end of the generated prefix, you can define a specific path. An asterisk * is allowed to indicate any bucket. An example is given as follows: *obs:::bucket:**
Object	[Format] *obs:::object:*Bucket name/Object name [Notes] IAM automatically generates the prefix *obs:::object:* for object resource paths. By adding Bucket name/Object name to the end of the generated prefix, you can define a specific path. An asterisk * is allowed to any object in the bucket. An example is given as follows: obs:::object:my-bucket/my-object/* (indicating any object in the my-object directory of bucket my-bucket)

OBS Request Conditions

Request conditions are useful in determining when a custom policy is in effect. A request condition consists of condition keys and operators. Condition keys are either global or service-level and are used in the Condition element of a policy statement. Global condition keys (starting with g:) are available for operations of all services, while service-specific condition keys (starting with a service name acronym like obs:) are available only for operations of that service. An operator is used together with a condition key to form a complete condition statement.

OBS has a group of predefined condition keys that can be used in IAM. For example, to define an "Allow" permission, use the condition key obs:SourceIp to filter matching requesters by IP address.

The condition keys and operators supported by OBS are the same as those in bucket policies. When configuring condition keys in IAM, start them with obs:. For details, see Bucket Policy Parameters.

Parent Topic: Using IAM to Grant Access to OBS

Previous topic: Using IAM to Grant Access to OBS

Next topic: Using IAM Identity Policies to Grant Access to OBS (New IAM Console)