Using IAM Roles or Policies to Grant Access to DDS

Prerequisites

Before granting permissions to user groups, learn about system-defined permissions in for DDS. To grant permissions for other services, learn about all system-defined permissions supported by IAM.

Process Flow

Figure 1 Process of granting DDS permissions using role/policy-based authorization

1. On the IAM console, create a user group and grant it permissions (DDS ReadOnlyAccess as an example).
2. Create an IAM user and add it to the user group created in 1.
3. Log in as the IAM user and verify permissions.
   In the authorized region, perform the following operations:

   • Choose Service List > Document Database Service. Then click Buy DB Instance on the DDS console. If a message appears indicating that you have insufficient permissions to perform the operation, the DDS 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 DDS ReadOnlyAccess policy is in effect.

Example Custom Policies

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

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 grammar.
• JSON: Create a JSON policy or edit an existing one.

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

• Example 1: Grant permission to create DDS instances.

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

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

  {
      "Version": "1.1",
      "Statement": [
          {
            "Effect": "Deny"
            "Action": [
                  "dds:instance:deleteInstance"
              ],
            }
      ]
  }

• Example 3: Create a custom policy containing multiple actions.

  A custom policy can contain the actions of one or multiple services that are of the same type (global or project-level). Example policy containing multiple actions:

  {  
          "Version": "1.1",  
          "Statement": [  
                  {  
                          "Action": [  
                                  "dds:instance:create",  
                                  "dds:instance:modify",  
                                  "dds:instance:deleteInstance",  
                   "vpc:publicIps:list",  
                   "vpc:publicIps:update"  
                          ],  
                          "Effect": "Allow"  
                  }  
          ]  
  }

• Example 4: Configure a resource policy.
  A custom policy can be configured with resources, indicating which resources the current action can operate on. Currently, the instance name can be configured. The asterisk (*) can be used as a wildcard. Example policy authorizing resources

  {
      "Version": "1.1",
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "dds:instance:list"
              ]
          },
          {
              "Effect": "Allow",
              "Action": [
                  "dds:instance:modify"
              ],
              "Resource": [
                  "DDS:*:*:instanceName:dds-*"
              ]
          }
      ]
  }

DDS Resources

A resource is an object that exists within a service. DDS resources include instances. To select these resources, specify their paths.

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

DDS has a group of condition keys predefined in IAM. For example, you can use hw:SourceIp to filter specified requesters' IP addresses and then allow actions. The following table lists the DDS predefined condition keys.