Creating an IAM User and Granting DMS for RabbitMQ Permissions

Use Identity and Access Management (IAM) to implement fine-grained permissions control over your Distributed Message Service (DMS) for RabbitMQ resources. With IAM, you can:

Create IAM users for personnel based on your enterprise's organizational structure. Each IAM user has their own identity credentials for accessing DMS for RabbitMQ 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 efficient O&M on your DMS for RabbitMQ resources.

If your HUAWEI ID meets your permissions requirements, you can skip this section.

This section describes the procedure for granting user permissions. Figure 1 shows the process flow.

Prerequisites

Learn about the permissions (see System-defined roles and policies supported by DMS for RabbitMQ) supported by DMS for RabbitMQ and choose policies according to your requirements. For the system policies of other services, see System Permissions.

Process Flow

Figure 1 Process of granting DMS for RabbitMQ permissions

For the following example, create a user group on the IAM console,
and assign the DMS ReadOnlyAccess policy to the group.
Create an IAM user and add it to the created user group.
Log in as the IAM user and verify permissions.
In the authorized region, perform the following operations:
- Choose Service List > Distributed Message Service (for RabbitMQ). Then click Buy Instance on the console of DMS for RabbitMQ. If a message appears indicating that you have insufficient permissions to perform the operation, the DMS ReadOnlyAccess policy is in effect.
- Choose Service List > Elastic Volume Service. If a message appears indicating that you have insufficient permissions to access the service, the DMS ReadOnlyAccess policy is in effect.
- Choose Service List > Distributed Message Service (for RabbitMQ). The RabbitMQ console is displayed. If a list of RabbitMQ instances are displayed, the DMS ReadOnlyAccess policy is in effect.

Example Custom Policies

You can create custom policies to supplement the system-defined policies of DMS for RabbitMQ. For details about actions supported in custom policies, see Permissions and Supported 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 DMS for RabbitMQ custom policies.

DMS for RabbitMQ permissions policies are based on DMS. Therefore, when assigning permissions, select DMS permissions policies.

Example 1: Grant permission to create and delete instances.

{
    "Version": "1.1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dms:instance:create",
                "dms:instance:delete"
            ]
        }
    ]
}

Example 2: Grant permission to deny instance deletion.
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 DMS FullAccess policy to a user but want to prevent them from deleting instances. You can create a custom policy for denying instance deletion, and attach this policy together with the DMS FullAccess policy to the user. As an explicit deny in any policy overrides any allows, the user can perform all operations on DMS for RabbitMQ excepting deleting instances.

Example policy denying instance deletion:
```
{
        "Version": "1.1",
        "Statement": [
                {
                        "Effect": "Deny",
                        "Action": [
                                "dms:instance:delete"
                        ]
                }
        ]
}
```

DMS for RabbitMQ Resources

A resource is an object that exists within a service. DMS for RabbitMQ resources include rabbitmq. To select these resources, specify their paths.

**Table 1** DMS for RabbitMQ resources and their paths
Resource	Resource Name	Path
rabbitmq	Instance	[Format] DMS::: rabbitmq: instance ID [Note] For instance resources, IAM automatically generates the prefix (*DMS:::rabbitmq:) of the resource path. For the path of a specific instance, add the instance ID* to the end. You can also use an asterisk * to indicate any instance. For example: DMS:::rabbitmq:* indicates any RabbitMQ instance.

DMS for RabbitMQ 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 such as dms:) are available only for operations of specific services. An operator must be used together with a condition key to form a complete condition statement.

DMS for RabbitMQ has a group of predefined condition keys that can be used in IAM. For example, to define an "Allow" permission, use the condition key dms:ssl to filter instances by SSL configurations. The following table lists the DMS for RabbitMQ predefined condition keys.