Role/Policy-based Authorization (Old IAM Version)

Prerequisites

• Before granting permissions to user groups, get familiar with the system policies listed 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.

Process Flow

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

1. Create a user group and grant it permissions.

   On the IAM console, create a user group and grant it CCE read-only permissions (CCE ReadOnlyAccess as an example).

   

   CCE is deployed by region. On the IAM console, select Region-specific projects when assigning CCE permissions.

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

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

   

   IAM users need programmatic and management console access to use CCE.

3. Log in as the IAM user and verify permissions.

   Log in to the management console as the user you created, and verify that the user has the assigned permissions.

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

System Roles Supported by CCE

Roles are a type of coarse-grained authorization mechanism that defines service-level permissions based on user responsibilities. Only a limited number of service-level roles are available for authorization. Roles are not ideal for fine-grained authorization and least privilege access.

The preset system role for CCE in IAM is CCE Administrator. When assigning this role to a user group, you must also select other roles and policies on which this role depends, such as Tenant Guest, Server Administrator, ELB Administrator, OBS Administrator, SFS Administrator, SWR Admin, and APM FullAccess. For more information about dependencies, see System-defined Permissions.

System Policies Supported by CCE

The system policies preset for CCE in IAM are CCE FullAccess and CCE ReadOnlyAccess.

• CCE FullAccess: common operation permissions on CCE cluster resources, excluding the namespace permissions for the clusters (with Kubernetes RBAC enabled) and the privileged administrator operations, such as agency configuration and cluster certificate generation
• CCE ReadOnlyAccess: permissions to view CCE cluster resources, excluding the namespace permissions of the clusters (with Kubernetes RBAC enabled)

When purchasing a cluster or node that is billed on a yearly/monthly basis, add custom policies and configure payment permissions such as bss:*:* for the Billing Center.

Example Custom Policies

Custom policies can be created as a supplement to the system-defined policies of CCE. For details about actions supported in custom policies, see Permissions 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 grammar.
• JSON: Create a JSON policy or edit an existing one.

For details, see Creating a Custom Policy. This section provides examples of common custom FunctionGraph policies.

Examples

• Example 1: Creating a cluster

  {
      "Version": "1.1",
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "cce:cluster:create"
              ]
          }
      ]
  }

• Example 2: Denying node deletion

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

  If you want to grant the CCEFullAccess permission to a user but prevent them from deleting nodes (cce:node:delete), you can create a custom policy that denies node deletion. Then, attach this policy with the CCEFullAccess policy to the user. Since an explicit denial in any policy takes precedence over any allowances, the user will have permission to perform all operations on nodes except for deleting them. The following is an example of a deny policy:

  {
      "Version": "1.1",
      "Statement": [
          {
              "Effect": "Deny",
              "Action": [
                  "cce:node:delete"
              ]
          }
      ]
  }

• Example 3: Creating a custom policy containing multiple actions

  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 multiple actions:

  {
      "Version": "1.1",
      "Statement": [
          {
              "Action": [
                  "ecs:cloudServers:resize",
                  "ecs:cloudServers:delete",
                  "ecs:cloudServers:delete",
                  "ims:images:list",
                  "ims:serverImages:create"
              ],
              "Effect": "Allow"
          }
      ]
  }

CCE Cluster Permissions and Enterprise Projects

CCE supports resource management and permission allocation by cluster and enterprise project.

Note that:

• IAM projects are based on physical isolation of resources, whereas enterprise projects provide global logical groups of resources, which better meet the actual requirements of enterprises. In addition, IAM policies can be managed based on enterprise projects. Therefore, use enterprise projects for permissions management. For details, see Creating an Enterprise Project.
• When there are both IAM projects and enterprise projects, IAM preferentially matches the IAM project policies.
• When creating a cluster or node using purchased cloud resources, ensure that IAM users have been granted the required permissions in the enterprise project to use these resources. Otherwise, the cluster or node may fail to be created.
• If a resource does not support enterprise projects, the permissions granted to the resource will not take effect.

  Resource Type	Resource	Description
  Supporting enterprise projects	cluster	Cluster
  	node	Node
  	nodepool	Node pool
  	job	Job
  	tag	Cluster label
  	addonInstance	Add-on pod
  	release	Helm release
  	storage	Storage
  Not supporting enterprise projects	quota	Cluster quota
  	chart	Chart
  	addonTemplate	Add-on template