Permissions Management

UCS Permission Types

UCS provides refined permission management based on the role access control (RBAC) capability of IAM and Kubernetes. Permission control can be implemented by UCS service resource and Kubernetes resource in a cluster. The two permission types apply to different resource types and are granted using different methods.

• UCS resource permissions are granted based on the system policies of IAM. UCS resources include fleets, clusters, and federation instances. Administrators can grant different permissions to different user roles (such as development and O&M) to control their use of UCS resources.
• Kubernetes resource permissions in a cluster are granted based on the Kubernetes RBAC capability. Refined permissions can be granted to Kubernetes resource objects in a cluster. With permission settings, the permissions for performing operations on different Kubernetes resource objects (such as workloads, jobs, and services) will vary with users.

If your team mainly uses UCS resources, IAM system-defined policies can meet your requirements. If you need refined permissions on Kubernetes resource objects in a cluster, use IAM system-defined policies together with Kubernetes RBAC.

UCS Resource Permissions (IAM-based)

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

UCS is a global service deployed in all physical regions. When you set the authorization scope to Global services, users have permissions to access UCS in all regions.

You can grant users 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 IAM users only permissions to manage a certain type of fleets and clusters.

Table 1 lists all system-defined permissions for UCS.

Services on Huawei Cloud are interdependent, so UCS depends on other cloud services to implement some functions such as image repository and domain name resolution. The preceding four system-defined policies are often used together with roles or policies of other cloud services for refined authorization. When granting permissions to IAM users, the administrator must comply with the principle of least privilege. Table 2 lists the least-privilege permissions required by the Administrator, Developer, and Viewer roles to use each UCS function.

Kubernetes Resource Permissions in a Cluster (Kubernetes RBAC-based)

Kubernetes resource permissions in a cluster are based on Kubernetes RBAC. The administrator can grant users refined permissions on specific Kubernetes resource objects in a cluster. These are cluster- and namespace-level resources. Refined operation permissions include get, list, watch, create, update, patch, and delete. The permissions take effect on the namespaces of a fleet or a cluster that is not added to any fleet. The operation permissions details are as follows:

• get retrieves a specific resource object by name.
• list retrieves all resource objects of a specific type in the namespace.
• watch responds to resource changes.
• create creates a resource.
• update updates a resource.
• patch updates resources partially.
• delete deletes a resource.

For details about cluster- and namespace-level resources, see Kubernetes Resource Objects.

For example, after permission policies are configured according to the scheme shown in Figure 1, user A can only perform get, list, and watch (read-only) operations on Deployments, pods, and Services in namespace A of the fleet, and user B can perform all operations on all resources in namespace B of the fleet.

Figure 1 Granting permissions on Kubernetes resources

Five common permission types are available on the UCS console: Administrator, O&M, Developer, Viewer, and Custom. You can grant these permission types to users. If these permission types cannot meet your requirements, you can configure custom permissions by specifying the operation type and resource object.