Permissions

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 policies can meet your requirements. If you need refined permissions on Kubernetes resource objects in the cluster, use IAM system policies together with Kubernetes RBAC.

UCS Resource Permissions

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.

UCS is a global service deployed for all 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 the system-defined permissions for UCS.

Services on Huawei Cloud are interdependent, and UCS depends on other cloud services to implement some functions, such as image repository and domain name resolution. Therefore, the preceding four system policies are often used together with roles or policies of other cloud services for refined permission granting. When granting permissions to IAM users, the administrator must comply with the principle of least privilege. Table 2 lists the minimum permissions of the admin, developer, and viewer permission types required by each UCS function.

Kubernetes Resource Permissions in a Cluster

Kubernetes resource permissions in a cluster are granted according to Kubernetes RBAC. The administrator can grant users refined permissions on specific Kubernetes resource objects in the cluster. These resources are cluster-level and namespace-level. Refined operation permissions include get, list, watch, create, update, patch, and delete. The permissions take effect on the namespaces of a fleet or on clusters that are not added to the fleet. The operation permissions are described 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-level 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 perform get, list, and watch (read-only) operations only 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

Three common permission types are available on the UCS console: admin, developer, and viewer. You can grant these permission types to users. If these permission types cannot meet your requirements, you can customize permissions by specifying the operation type and resource object.