Granting Cluster Permissions to an IAM User
CCE cluster-level permissions are assigned based on IAM system policies and custom policies. You can use user groups to assign permissions to IAM users.
- Cluster permissions are granted to users for operating cluster-related resources only (such as clusters and nodes). To operate Kubernetes resources like workloads and Services, you must be granted the namespace permissions as well.
- When viewing a cluster on the CCE console, the information displayed depends on the namespace permissions. If you have no namespace permissions, you cannot view the resources in the cluster. For details, see Permission Dependency of the CCE Console.
Prerequisites
- Before granting permissions to user groups, get familiar with the system policies listed in Permissions for CCE. For the system policies of other services, see System Permissions.
- 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.
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 page. This section describes the operations in IAM.
Process Flow
- Create a user group and assign permissions to it.
Create a user group on the IAM console, and assign CCE permissions, for example, the CCE ReadOnlyAccess policy to the group.
CCE is deployed by region. On the IAM console, select Region-specific projects when assigning CCE permissions.
- Create a user and add it to a 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.
- Log in and verify permissions.
Log in to the management console as the user you created, and verify that the user has the assigned permissions.
- Log in to the management console, switch to the CCE console, and buy a cluster. If you fail to do so (assuming that only the CCE ReadOnlyAccess permission is assigned), the CCE ReadOnlyAccess policy has already taken effect.
- Switch to the console of any other service. If a message appears indicating that you do not have the required permissions for accessing the service, the CCE ReadOnlyAccess policy has already taken effect.
System-defined Roles
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 Permissions.
System-defined Policies
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-level 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-level 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.
Action |
Specific Action |
Description |
---|---|---|
cce:*:* |
cce:cluster:create |
Create a cluster. |
cce:cluster:delete |
Delete a cluster. |
|
cce:cluster:update |
Update a cluster. For example, update cluster node scheduling parameters and provide RBAC support to clusters. |
|
cce:cluster:upgrade |
Upgrade a cluster. |
|
cce:cluster:start |
Wake up a cluster. |
|
cce:cluster:stop |
Hibernate a cluster. |
|
cce:cluster:list |
List all clusters. |
|
cce:cluster:get |
Obtain cluster details. |
|
cce:node:create |
Add a node. |
|
cce:node:delete |
Delete one or more nodes. |
|
cce:node:update |
Update a node. For example, update the node name. |
|
cce:node:get |
Obtain node details. |
|
cce:node:list |
List all nodes. |
|
cce:nodepool:create |
Create a node pool. |
|
cce:nodepool:delete |
Delete a node pool. |
|
cce:nodepool:update |
Update a node pool. |
|
cce:nodepool:get |
Obtain a node pool. |
|
cce:nodepool:list |
List all node pools in a cluster. |
|
cce:release:create |
Create a release. |
|
cce:release:delete |
Delete a release. |
|
cce:release:update |
Update a release. |
|
cce:job:list |
List all cluster jobs. |
|
cce:job:delete |
Delete one or more cluster jobs. |
|
cce:job:get |
Obtain a specific cluster job. |
|
cce:storage:create |
Create a storage volume. |
|
cce:storage:delete |
Delete a storage volume. |
|
cce:storage:list |
List all volumes. |
|
cce:addonInstance:create |
Create an add-on instance. |
|
cce:addonInstance:delete |
Delete an add-on instance. |
|
cce:addonInstance:update |
Update an add-on instance. |
|
cce:addonInstance:get |
Obtain an add-on instance. |
|
cce:addonTemplate:get |
Obtain an add-on template. |
|
cce:addonInstance:list |
List all add-on instances. |
|
cce:addonTemplate:list |
List all add-on templates. |
|
cce:chart:list |
List all charts. |
|
cce:chart:delete |
Delete a chart. |
|
cce:chart:update |
Update a chart. |
|
cce:chart:upload |
Upload a chart. |
|
cce:chart:get |
Obtain information about a chart. |
|
cce:release:get |
Obtain information about a release. |
|
cce:release:list |
List all releases. |
|
cce:userAuthorization:get |
Obtain CCE user authorization. |
|
cce:userAuthorization:create |
Create CCE user authorization. |
|
ecs:*:* |
None |
Perform all operations on Elastic Cloud Server (ECS). |
evs:*:* |
- |
Perform all operations on Elastic Volume Service (EVS). EVS disks can be attached to cloud servers and expanded to a higher capacity whenever needed. |
vpc:*:* |
None |
Perform all operations on VPC, including enhanced ELB load balancers. A cluster must run in a VPC. When creating a namespace, create or associate a VPC for the namespace so that all containers in the namespace will run in the VPC. |
bms:*:get* |
None |
View BMS resource details. |
bms:*:list* |
None |
List all BMS resources. |
ims:*:get* |
None |
View IMS resource details. |
ims:*:list* |
None |
List all IMS resources. |
elb:*:get |
None |
View ELB resource details. |
elb:*:list |
None |
List all ELB resources. |
nat:*:get |
None |
View NAT Gateway resource details. |
nat:*:list |
None |
List all NAT Gateway resources. |
sfs:*:get* |
None |
View SFS resource details. |
sfs:shares:ShareAction |
None |
Share SFS resources for scaling. |
sfsturbo:*:get* |
None |
View SFS Turbo resource details. |
sfsturbo:shares:ShareAction |
None |
Share SFS Turbo resources for scaling. |
tms:resourceTags:list |
None |
List TMS resources. |
kps:domainKeypairs:list |
None |
List DEW SSH keys. |
kps:domainKeypairs:get |
None |
View DEW SSH keys. |
kms:cmk:get |
None |
View DEW keys. |
kms:cmk:list |
None |
List DEW keys. |
aom:*:get |
None |
View AOM resource details. |
aom:*:list |
None |
List AOM resources. |
aom:autoScalingRule:* |
None |
Perform all operations on AOM auto scaling rules. |
apm:icmgr:* |
None |
Perform operations on the ICAgent in Application Performance Management (APM). |
lts:*:* |
None |
Perform all operations on Log Tank Service (LTS). |
smn:*:* |
None |
Perform all operations on SMN. |
Action |
Specific Action |
Description |
---|---|---|
cce:*:get |
cce:cluster:get |
Obtain cluster details. |
cce:node:get |
Obtain node details. |
|
cce:job:get |
Obtain a specific cluster job. |
|
cce:addonInstance:get |
Obtain an add-on instance. |
|
cce:addonTemplate:get |
Obtain an add-on template. |
|
cce:chart:get |
Obtain a chart. |
|
cce:nodepool:get |
Obtain a node pool. |
|
cce:release:get |
Obtain a release. |
|
cce:userAuthorization:get |
Obtain CCE user authorization. |
|
cce:*:list |
cce:cluster:list |
List all clusters. |
cce:node:list |
List all nodes. |
|
cce:job:list |
List all cluster jobs. |
|
cce:addonInstance:list |
List all add-on instances. |
|
cce:addonTemplate:list |
List all add-on templates. |
|
cce:chart:list |
List all charts. |
|
cce:nodepool:list |
List all node pools in a cluster. |
|
cce:release:list |
List all releases. |
|
cce:storage:list |
List all volumes. |
|
cce:kubernetes:* |
None |
Perform operations on all Kubernetes resources. For details, see Namespace Permissions. |
ecs:*:get |
None |
View details about all ECS resources. An ECS with multiple EVS disks is a cluster node in CCE. |
ecs:*:list |
None |
List all ECS resources. |
bms:*:get* |
None |
View BMS resource details. |
bms:*:list |
None |
List all BMS resources. |
ims:*:get* |
None |
View IMS resource details. |
ims:*:list* |
None |
List all IMS resources. |
evs:*:get |
None |
View EVS resource details. EVS disks can be attached to cloud servers and expanded to a higher capacity whenever needed. |
evs:*:list |
None |
List all EVS resources. |
evs:*:count |
None |
None |
vpc:*:get |
None |
View VPC resource details. A cluster must run in a VPC. When creating a namespace, create or associate a VPC for the namespace so that all containers in the namespace will run in the VPC. |
vpc:*:list |
None |
List all VPC resources. |
elb:*:get |
None |
View ELB resource details. |
elb:*:list |
None |
List all ELB resources. |
nat:*:get |
None |
View NAT Gateway resource details. |
nat:*:list |
None |
List all NAT Gateway resources. |
sfs:*:get* |
None |
View SFS resource details. |
sfs:shares:ShareAction |
None |
Share SFS resources for scaling. |
sfsturbo:*:get* |
None |
View SFS Turbo resource details. |
sfsturbo:shares:ShareAction |
None |
Share SFS Turbo resources for scaling. |
tms:resourceTags:list |
None |
List TMS resources. |
kps:domainKeypairs:list |
None |
List DEW SSH keys. |
kps:domainKeypairs:get |
None |
View DEW SSH keys. |
kms:cmk:get |
None |
View DEW keys. |
kms:cmk:list |
None |
List DEW keys. |
aom:*:get |
None |
View AOM resource details. |
aom:*:list |
None |
List all AOM resources. |
aom:autoScalingRule:* |
None |
Perform all operations on AOM auto scaling rules. |
lts:*:get |
None |
View details about all LTS resources. |
lts:*:list |
None |
List all LTS resources. |
smn:*:get |
None |
View SMN resource details. |
smn:*:list |
None |
List SMN resources. |
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 Policies 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 syntax.
- JSON: Edit JSON policies from scratch or based on an existing policy.
For details, see Creating a Custom Policy. This section provides examples of common custom CCE policies.
Example Custom Policies:
- Example 1: Creating a cluster named test
{ "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.
The following method can be used if you need to assign permissions of the CCEFullAccess policy to a user but you want to prevent the user from deleting nodes (cce:node:delete). Create a custom policy for denying node deletion, and attach both policies to the group to which the user belongs. Then, the user can perform all operations on CCE except deleting nodes. The following is an example of a deny policy:
{ "Version": "1.1", "Statement": [ { "Effect": "Deny", "Action": [ "cce:node: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": [ { "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 Name
Description
Supporting enterprise projects
cluster
Cluster
node
Node
nodepool
Node pool
job
Job
tag
Cluster label
addonInstance
Add-on instance
release
Helm release
storage
Storage
Not supporting enterprise projects
quota
Cluster quota
chart
Chart
addonTemplate
Add-on template
CCE Cluster Permissions and IAM RBAC
CCE is compatible with IAM system roles for permissions management. Use fine-grained policies provided by IAM to simplify permissions management.
CCE supports the following roles:
- Basic IAM roles:
- te_admin (Tenant Administrator): Users with this role can call all APIs of all services except IAM.
- readonly (Tenant Guest): Users with this role can call APIs with the read-only permissions of all services except IAM.
- Custom CCE administrator role: CCE Administrator
If a user has the Tenant Administrator or CCE Administrator system role, the user has the cluster-admin permissions in Kubernetes RBAC and the permissions cannot be removed after the cluster is created.
- Method 1: Choose Permissions Management > Namespace-Level Permissions > Delete in the same role as cluster-creator on the CCE console.
- Method 2: Delete ClusterRoleBinding: cluster-creator through the API or kubectl.
When RBAC and IAM policies co-exist, the backend authentication logic for open APIs or console operations on CCE is as follows.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot