Permissions

Updated on 2025-01-03 GMT+08:00

View PDF

CCE Autopilot permissions management allows you to assign permissions to IAM users and user groups under your tenant accounts. It 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 Autopilot permissions are 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, 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.
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 Autopilot has also been enhanced based on open-source capabilities. It supports RBAC authorization based on IAM users or user groups, 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.

CAUTION:

Cluster-level permissions are configured only for cluster-related resources (such as clusters and charts). You must also configure namespace permissions to operate Kubernetes resources (such as workloads, jobs, and Services).
After you create a cluster, CCE Autopilot will automatically grant you the cluster-admin permission. This gives you complete control over all resources in all namespaces within 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 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. When you set Scope to Region-specific projects and select the specified projects in the specified regions, the users only have permissions for CCE in the selected projects. If you select All projects, the users have permissions for CCE in all region-specific projects. When accessing CCE, the users need to switch to the authorized region.

You can grant permissions by using roles and policies.

Roles: A coarse-grained authorization strategy that defines permissions by job responsibility. Only a limited number of service-level roles are available for authorization. Cloud services often depend on each other. When you grant permissions using roles, you also need to attach any existing role dependencies. Roles are not ideal for fine-grained authorization and least privilege access.
Policies: A fine-grained authorization strategy that defines permissions required to perform operations on specific cloud resources under certain conditions. This type of authorization is more flexible and is ideal for least privilege access. For example, you can grant users only permission to manage a certain type of clusters and nodes. A majority of fine-grained policies contain permissions for specific APIs, and permissions are defined using API actions. For the API actions supported by CCE, see Permissions 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, jobs, and Services) in the clusters.	System-defined role	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: To grant cluster namespace permissions to other users or user groups, an IAM user must have 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	x	√	√
Deleting a cluster	x	√	√
Updating a cluster, for example, updating cluster node scheduling parameters and providing RBAC support to clusters	x	√	√
Upgrading a cluster	x	√	√
Listing all clusters	√	√	√
Obtaining cluster details	√	√	√
Listing all cluster jobs	√	√	√
Deleting one or more cluster jobs	x	√	√
Obtaining job details	√	√	√
Creating a storage volume	x	√	√
Deleting a storage volume	x	√	√
Performing operations on all Kubernetes resources	√ (Kubernetes RBAC authorization required)	√ (Kubernetes RBAC authorization required)	√
Viewing all resources in Monitoring Center	√	√	√
Performing operations on all resources in Monitoring Center	x	√	√
Performing all operations on NAT Gateway resources	x	√	√
Viewing NAT Gateway resource details	√	√	√
Listing all NAT Gateway resources	√	√	√
Performing all operations on VPC Endpoint resources	x	√	√
Viewing VPC Endpoint resource details	√	√	√
Listing all VPC Endpoint resources	√	√	√
Performing all operations on EVS disks EVS disks can be attached to workloads and scaled to a higher capacity whenever needed.	x	√	√
Performing all operations on VPCs 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.	x	√	√
Viewing details about all EVS disk resources. EVS disks can be attached to workloads and scaled to a higher capacity whenever needed.	√	√	√
Listing all EVS resources	√	√	√
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.	√	√	√
Listing all VPC resources	√	√	√
Viewing details about all ELB resources	√	√	√
Listing all ELB resources	√	√	√
Viewing details about all SFS resources	√	√	√
Listing all SFS resources	√	√	√
Viewing details about all AOM resources	√	√	√
Listing all AOM resources	√	√	√
Performing all operations on AOM auto scaling rules	√	√	√

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 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.

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