Creating a User and Granting DMS for RocketMQ Permissions

Prerequisites

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

Process Flow

Figure 1 Process for granting DMS for RocketMQ permissions

1. On the IAM console, create a user group and grant it permissions.

   DMS ReadOnlyAccess is used as an example.

2. Create an IAM user and add it to the created user group.
3. Log in as the IAM user and verify permissions.

   In the authorized region, perform the following operations:

   • Choose Service List > Distributed Message Service (for RocketMQ). Then click Buy Instance on the console of DMS for RocketMQ. 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.

Example Custom Policies

Custom policies can be created to supplement the system-defined policies of DMS for RocketMQ. For the actions that can be added for custom policies, see Permissions Policies and Supported Actions.

You can create custom policies in either of the following ways:

• 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. This section lists examples of common DMS for RocketMQ custom policies.

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

• Example 1: Grant permission to delete and restart instances.

  {
      "Version": "1.1",
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "dms:instance:modifyStatus",
                  "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 RocketMQ excepting deleting instances.

  Example policy denying instance deletion:

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

DMS for RocketMQ 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 RocketMQ 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 RocketMQ predefined condition keys.