Using IAM Roles or Policies to Grant Access to Direct Connect

Prerequisites

Before granting permissions to user groups, learn about system-defined permissions in Role/Policy-based Permissions Management for Direct Connect. To grant permissions for other services, learn about all system-defined permissions.

Process Flow

Figure 1 Process for granting Direct Connect permissions

1. Create a user group and assign permissions.

   Create a user group on the IAM console and assign the Direct Connect Administrator policy to the group.

2. Create a user and add the user to the user group.

   Create a user on the IAM console and add the user to the group created in 1.

3. Log in to the management console as the created user and verify the permissions.

   Log in to the Direct Connect console as the created user, switch to the authorized region, and verify the permissions.

   • Go to the connection list page and click Create Connection in the upper right corner. If the connection is successfully created, the Direct Connect Administrator policy has already taken effect.
   • Choose any other service in the Service List. A message will appear indicating that you have no sufficient permissions to access the service.

Example Custom Policies

Custom policies can be created to supplement the system-defined policies of Direct Connect. For the actions supported for custom identity policies, see "Role/Policy-Based Authorization" in the Direct Connect API Reference.

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 grammar.
• JSON: Edit JSON policies from scratch or based on an existing policy.

For details, see Creating a Custom Policy. The following are example custom policies created for Direct Connect.

• Example 1: Allowing users to update a virtual gateway

  {
      "Version": "1.1",
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "dcaas:vgw:update"
              ]
          }
      ]
  }

• Example 2: Denying users to delete a connection

  A policy with only "Deny" permissions must be used in conjunction with other policies to take effect. If permissions assigned to a user contain both Allow and Deny actions, the Deny action takes precedence over the Allow action.

  The following method can be used if you need to assign permissions of the DCAAS FullAccess policy to a user but also forbid the user from deleting connections. Create a custom policy for denying connection deletion, and assign both policies to the group the user belongs to. Then the user can perform all operations on Direct Connect except deleting connections.

  The following is an example of a deny policy:

  {
      "Version": "1.1",
      "Statement": [
          {
              "Effect": "Deny",
              "Action": [
                  "dcaas:directConnect:delete"
              ]
          }
      ]
  }

• Example 3: Defining permissions for multiple services in a policy

  A custom policy can contain the actions of multiple services that are of the global or project-level type.

  The following is an example policy containing actions of multiple services:

  {
      "Version": "1.1",
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "vpc:vpcs:list",
                  "vpc:subnets:get",
                  "vpc:routes:list"
              ]
          },
          {
              "Effect": "Allow",
              "Action": [
                  "dcaas:vif:list",
                  "dcaas:vgw:list",
                  "dcaas:directConnect:list"
              ]
          }
      ]
  }