Identity Policy-based Authorization (New IAM Version)

Prerequisites

• Before granting permissions, learn about system-defined identity policies in Permissions for CCE. To grant permissions for other services, learn about all system-defined permissions supported by IAM.
• A user with the Security Administrator role (for example, your account) has all IAM permissions except role switching. Only these users can view user groups and their permissions on the Permissions page on the CCE console.
• If a service control policy in an organization is used for permission control, the request for creating yearly/monthly resources cannot be intercepted. For example, if an SCP policy for intercepting ECS creation is configured, yearly/monthly ECSs can still be created on CCE.

Configuration

On the CCE console, when you choose Permissions > Cluster-Level Permissions to create a user group, you will be directed to the IAM console to complete the process. After the user group is created and its permissions are configured, you can view the information on the Cluster-Level Permissions tab. This section describes the operations in IAM.

Process Flow

Figure 1 Process of granting CCE permissions using identity policy-based authorization

1. Log in to the IAM console and create a user or user group.

2. Attach a system-defined identity policy to the user or user group.

   Attach the system-defined identity policy CCEReadOnlyPolicy to the user or user group.

3. Log in as an IAM user and verify permissions.
   In the authorized region, perform the following operations:

   • Choose Service List > Cloud Container Engine. Then click Buy Cluster on the CCE console. If the operation failed, CCEReadOnlyPolicy is in effect.
   • Choose another service from Service List. If a message appears indicating that you have insufficient permissions to access the service, CCEReadOnlyPolicy takes effect.

Example Custom Identity Policies

You can create custom identity policies to supplement the system-defined identity policies of CCE.

To create a custom identity policy, choose either of the following ways:

• Visual editor: Select cloud services, actions, resources, and request conditions. No knowledge of policy syntax is required.
• JSON: Create a JSON policy or edit an existing one.

For details, see Creating a Custom Identity Policy and Attaching It to a Principal.

When creating a custom identity policy, use the Resource element to specify the resources the identity policy applies to and use the Condition element (service-specific condition keys) to control when the identity policy is in effect. The following lists examples of common CCE custom identity policies.

• Example 1: Grant permission to create and delete a cluster.

  {
      "Version": "5.0",
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "cce:cluster:createCluster",
                  "cce:cluster:delete"
              ]
          }
      ]
  }

• Example 2: Create a custom identity policy containing multiple actions.

  A custom identity policy can contain the actions from one or more services. The following is an example policy containing multiple actions:

  {
      "Version": "5.0",
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "cce:cluster:createCluster",
                  "cce:cluster:delete"
              ]
          },
          {
              "Effect": "Allow",
              "Action": [
                  "evs:volumes:create",
                  "evs:volumes:list"
              ]
          },
          {
              "Effect": "Allow",
              "Action": [
                  "ecs:cloudServers:createServers",
                  "ecs:cloudServers:listServersDetails"
              ]
          }
      ]
  }

CCE Resources

A resource is an object managed by a service. CCE supports cluster-scoped authorization. When creating a policy, specify a resource path to restrict access to specific resources.

Example: Forbid users from deleting cluster nodes that match a specific naming pattern, for example, nodes in clusters whose names start with test.

{
    "Version": "5.0",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "cce:node:delete"
            ],
            "Resource": [
                "CCE:*:*:cluster:test*"
            ]
        }
    ]
}