Using IAM Roles or Policies to Grant Access to Central Networks

Prerequisites

Before granting permissions to user groups, learn about system-defined permissions in Role/Policy-based Authorization for Cloud Connect. To grant permissions for other services, learn about all system-defined permissions supported by IAM.

Process Flow

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

1. Create a user group and grant permissions to it.

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

2. Create an IAM user and add it to the created user group.

   On the IAM console, create a 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:

   • In the service list, choose Networking > Cloud Connect. Click Create Cloud Connection in the upper right corner. If a message appears indicating that you have insufficient permissions to perform the operation, the Cross Connect Administrator policy is in effect.
   • Choose any other service in the service list. If a message appears indicating that you have insufficient permissions to access the service, the Cross Connect Administrator policy is in effect.

Example Custom Policies

Custom policies can be created to supplement system-defined policies. For the actions supported by custom policies, see Actions Supported by Policy-based Authorization in the Cloud 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: Create a JSON policy or edit an existing one.

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

• Example 1: Grant permission to delete central networks.

  {
      "Version": "1.1",
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "cc:centralNetwork:delete"
              ]
          }
      ]
  }

• Example 2: Grant permission to deny the deletion of central network policies.

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

  Assume that you want to grant the CC FullAccess policy to a user but want to prevent them from deleting central networks. You can create a custom policy for denying central network deletion, and attach this policy together with the CC FullAccess policy to the user. As an explicit deny in any policy overrides any allows, the user can perform all operations on central networks excepting deleting them. The following is an example of a deny policy:

  {
      "Version": "1.1",
      "Statement": [
          {
              "Effect": "Deny",
              "Action": [
                  "cc:centralNetwork:deletePolicy"
              ]
          }
      ]
  }

• 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). The following is a custom policy containing multiple actions:

  {
      "Version": "1.1",
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "cc:centralNetwork:create",
                  "cc:centralNetwork:update",
                  "cc:centralNetwork:delete",
                  "cc:centralNetwork:get"
              ]
          },
          {
              "Effect": "Allow",
              "Action": [
                  "er:instances:create",
                  "er:instances:update",
                  "er:instances:delete",
                  "er:instances:get"
              ]
          }
      ]
  }