Permissions

CCE permissions management allows you to assign permissions to IAM users and user groups under your tenant accounts. CCE combines the advantages of IAM and RBAC to provide a variety of authorization methods, including IAM fine-grained/token authorization and cluster-/namespace-scoped authorization.

CCE permissions are described as follows:

Cluster-level permissions: Cluster-level permissions management evolves out of the system policy authorization feature of IAM. IAM users in the same user group have the same permissions. A user group is simply a group of users. By granting cluster permissions to specific user groups, you can enable those users to perform various operations on clusters, including creating or deleting clusters, nodes, node pools, charts, and add-ons. In the meantime, you can restrict other user groups to only view clusters.
Cluster-level permissions involve non-Kubernetes native APIs and support fine-grained IAM policies and enterprise project management capabilities.
Namespace-level permissions: You can regulate users' or user groups' access to Kubernetes resources, such as workloads, jobs, and Services, in a single namespace based on their Kubernetes RBAC roles. CCE has also been enhanced based on open-source capabilities. It supports RBAC authorization based on IAM user or user group, and RBAC authentication on access to APIs using IAM tokens.
Namespace-level permissions involve CCE Kubernetes APIs and are enhanced based on the Kubernetes RBAC capabilities. Namespace-level permissions can be granted to IAM users or user groups for authentication and authorization, but are independent of fine-grained IAM policies. For details, see Using RBAC Authorization.

Cluster-level permissions are configured only for cluster-related resources (such as clusters and nodes). You must also configure namespace permissions to operate Kubernetes resources (such as workloads, jobs, and Services).
After you create a cluster, CCE automatically assigns the cluster-admin permission to you, which means you have full control on all resources in all namespaces in the cluster.
When viewing CCE resources on the console, the resources displayed depend on the namespace permissions. If no namespace permissions are granted, the console will not show you the resources.

Cluster-level Permissions (Assigned by Using IAM System Policies)

New IAM users do not have any permissions assigned by default. You need to first add them to one or more groups and then attach policies or roles to these groups. The IAM users then inherit permissions from the groups and can perform specified operations on cloud services based on the permissions they have been assigned.

CCE is a project-level service deployed for specific regions. To assign CCE permissions to a user group, specify the scope as region-specific projects and select projects for the permissions to take effect. If All projects is selected, the permissions will take effect for the user group in all region-specific projects. When accessing CCE, the users need to switch to the authorized region.

You can grant users permissions by using roles and policies.

Roles: A type of coarse-grained authorization mechanism that defines permissions related to user responsibilities. This mechanism provides only a limited number of service-level roles for authorization. When using roles to assign permissions, assign other roles on which the permissions depend to take effect. However, roles are not an ideal choice for fine-grained authorization and secure access control.
Policies: A type of fine-grained authorization mechanism that defines permissions required to perform operations on specific cloud resources under certain conditions. This mechanism allows for more flexible policy-based authorization, meeting requirements for secure access control. For example, you can assign users only the permissions for managing a certain type of clusters and nodes. Most policies define permissions based on APIs. For the API actions supported by CCE, see Permissions Policies and Supported Actions.

Table 1 lists all the system-defined permissions for CCE.

**Table 1** System-defined permissions for CCE
Role/Policy Name	Description	Type	Dependencies
CCE Administrator	Read and write permissions for CCE clusters and all resources (including workloads, nodes, jobs, and Services) in the clusters	System-defined roles	Users granted permissions of this policy must also be granted permissions of the following policies: Global service project: OBS Buckets Viewer and OBS Administrator Region-specific projects: Tenant Guest, Server Administrator, ELB Administrator, SFS Administrator, SWR Admin, and APM FullAccess NOTE: If you are assigned with both CCE Administrator and NAT Gateway Administrator permissions, you can use NAT Gateway functions for clusters. If an IAM user is required to grant cluster namespace permissions to other users or user groups, the user must have the IAM read-only permission.
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	Policy	None
CCE ReadOnlyAccess	Permissions to view CCE cluster resources, excluding the namespace-level permissions of the clusters (with Kubernetes RBAC enabled)	Policy	None

**Table 2** Common operations supported by system-defined permissions
Operation	CCE ReadOnlyAccess	CCE FullAccess	CCE Administrator
Creating a cluster	Not supported	Supported	Supported
Deleting a cluster	Not supported	Supported	Supported
Updating a cluster, for example, updating cluster node scheduling parameters and providing RBAC support to clusters	Not supported	Supported	Supported
Upgrading a cluster	Not supported	Supported	Supported
Waking up a cluster	Not supported	Supported	Supported
Hibernating a cluster	Not supported	Supported	Supported
Listing all clusters	Supported	Supported	Supported
Querying cluster details	Supported	Supported	Supported
Adding a node	Not supported	Supported	Supported
Deleting one or more nodes	Not supported	Supported	Supported
Updating a node. For example, changing the node name.	Not supported	Supported	Supported
Querying node details	Supported	Supported	Supported
Listing all nodes	Supported	Supported	Supported
Listing all jobs	Supported	Supported	Supported
Deleting one or more cluster jobs	Not supported	Supported	Supported
Querying job details	Supported	Supported	Supported
Creating a storage volume	Not supported	Supported	Supported
Deleting a storage volume	Not supported	Supported	Supported
Performing operations on all Kubernetes resources	Supported (Kubernetes RBAC required)	Supported (Kubernetes RBAC required)	Supported
Viewing all CIA resources	Supported	Supported	Supported
Performing operations on all CIA resources	Not supported	Supported	Supported
Performing all operations on ECSs	Not supported	Supported	Supported
Performing all operations on EVS disks EVS disks can be attached to cloud servers and scaled to a higher capacity whenever needed.	Not supported	Supported	Supported
Performing all operations on VPC 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.	Not supported	Supported	Supported
Viewing details of all resources on an ECS In CCE, a node is an ECS with multiple EVS disks.	Supported	Supported	Supported
Listing all resources on an ECS	Supported	Supported	Supported
Viewing details about all EVS disk resources EVS disks can be attached to cloud servers and scaled to a higher capacity whenever needed.	Supported	Supported	Supported
Listing all EVS resources	Supported	Supported	Supported
Viewing details about all VPC resources 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.	Supported	Supported	Supported
Listing all VPC resources	Supported	Supported	Supported
Viewing details about all ELB resources	Not supported	Not supported	Supported
Listing all ELB resources	Not supported	Not supported	Supported
Viewing details about all SFS resources	Supported	Supported	Supported
Listing all SFS resources	Supported	Supported	Supported
Viewing details about all AOM resources	Supported	Supported	Supported
Listing all AOM resources	Supported	Supported	Supported
Performing all operations on AOM auto scaling rules	Supported	Supported	Supported

Namespace-level Permissions (Assigned by Using Kubernetes RBAC)

You can regulate users' or user groups' access to Kubernetes resources in a single namespace based on their Kubernetes RBAC roles. The RBAC API declares four kinds of Kubernetes objects: Role, ClusterRole, RoleBinding, and ClusterRoleBinding, which are described as follows:

Role: defines a set of rules for accessing Kubernetes resources in a namespace.
RoleBinding: defines the relationship between users and roles.
ClusterRole: defines a set of rules for accessing Kubernetes resources in a cluster (including all namespaces).
ClusterRoleBinding: defines the relationship between users and cluster roles.

Role and ClusterRole specify actions that can be performed on specific resources. RoleBinding and ClusterRoleBinding bind roles to specific users, user groups, or ServiceAccounts. See the following figure.

Figure 1 Role binding
Click to enlarge

On the CCE console, you can assign permissions to a user or user group to access resources in one or multiple namespaces. By default, the CCE console provides the following ClusterRoles:

view (read-only): read-only permission on most resources in all or selected namespaces.
edit (development): read and write permissions on most resources in all or selected namespaces. If this ClusterRole is configured for all namespaces, its capability is the same as the O&M permission.
admin (O&M): read and write permissions on most resources in all namespaces, and read-only permission on nodes, storage volumes, namespaces, and quota management.
cluster-admin (administrator): read and write permissions on all resources in all namespaces.
drainage-editor: drain a node.
drainage-viewer: view the nodal drainage status but cannot drain a node.
geip-editor-role: use of global EIPs in the cluster, but only read and write permissions on GEIPs.
icagent-clusterRole: report Kubernetes event logs to LTS.

In addition to the preceding typical ClusterRoles, you can define Role and RoleBinding to grant permissions to add, delete, modify, and obtain resources (such as nodes, PVs, and CustomResourceDefinitions) and different resources (such as pods, Deployments, and Services) within specific namespaces. This allows for more precise permission control.