Kubernetes Resource Permissions in a Cluster

Permission Granting Process

Figure 1 Process for granting Kubernetes resource permissions to a user

1. Create a user.

   The administrator creates a user on the IAM console.

2. Grant the UCS system policy permission to the user.

   Before granting the Kubernetes resource permissions, you must grant the UCS system policy permission to the user. In this example, the UCS ReadOnlyAccess policy (read-only permission on UCS) must be granted.

3. Create a permission policy.

   The administrator creates a permission policy on the UCS console. Select the Viewer permission type, which indicates read-only permissions on all Kubernetes resource objects.

4. Associate the permission policy with a fleet or clusters not in the fleet.

   Associate the permission policy with a fleet. During the association, you need to select the namespace to which the permission policy applies. You can also associate the permission policy with clusters not in the fleet.

5. Verify the permission setting.

   Log in to the console as the created user, and verify whether the read-only permission takes effect.

Creating a Permission Policy

1. Log in to the UCS console. In the navigation pane, choose Permissions.
2. Click Create Permission Policy in the upper right corner.
3. Configure permission policy parameters.
   Figure 2 Creating a permission policy
   
   • Policy Name: Enter a name, starting with a lowercase letter and not ending with a hyphen (-). Only lowercase letters, digits, and hyphens (-) are allowed.
   • User: Select the newly created username from the drop-down list. You can select multiple users. Assume that the R&D employees of a company have the same operation permission on resources. When creating a permission policy, you can select multiple users to grant permissions to all these users.

     This section uses the readonly_user user as an example.

   • Type: Admin, Viewer, Developer, and Custom permissions are supported.

     Table 1 Permission types

     Permission Type	Description
     Admin	Read-write permissions on all cluster resource objects.
     Viewer	Read-only permissions on all cluster resource objects.
     Developer	Read-write permissions on most cluster resource objects and read-only permissions on cluster resource objects such as namespaces and resource quotas.
     Custom	Permissions are determined by the actions and resource objects you select.

   • Policy Details: indicates the actions allowed on specific resources. The Admin, Viewer, and Developer permission types have been templated. You can click to view the details of a permission type. When Type is set to Custom, configure Operation to perform and Resource Object.

     Operation to perform: You can add an operation type (for example, deletecollection indicates the deletion of multiple resources). The options 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.
     

     All operations: All

     Read-only: get + list + watch

     Read-write: get + list + watch + create + update + patch + delete

     Resource Object: Select All or Resources to operate. All includes existing resource objects and custom resource objects to be added. Resources to operate indicates the custom range of resource objects. UCS categorizes resource objects by workload, service, config and storage, authentication, authorization, policy, extend, and cluster.

     If the desired resource object does not exist in system resources, you can add a custom resource object.

     If the operation types vary according to resource objects (for example, you have the create and delete permissions on Deployments and the get, list, and watch permissions on secrets), you can click to add multiple groups of permissions.

     

     For details about resource objects and operation types, see Kubernetes API.

   • Description: Enter a description of the permission policy to be added.

4. Click OK. After the permission policy is created, you need to associate the permission policy with a fleet or clusters not in the fleet so that you can perform operations on Kubernetes resources.

Associating the Permission Policy with a Fleet or Clusters Not in the Fleet

A fleet contains multiple clusters and can implement unified permission management for these clusters. After clusters join a fleet, you are advised to associate the permission policy with the fleet so that clusters in the fleet can have the same permissions.

1. Log in to the UCS console. In the navigation pane, choose Fleets.
2. In the card view of the destination fleet, click in the upper right corner.
   Figure 3 Associating a permission policy with a fleet
   

3. On the displayed page, click Update Fleet Permissions. On the displayed page, associate the created permission policy with the namespace of the fleet.
   Figure 4 Updating a permission policy
   
   • Namespace: Select All namespaces or Namespace. All namespaces includes the existing namespace of the fleet and the namespace to be added to the fleet. Namespace indicates the custom range of namespaces. UCS provides several common namespaces, such as default, kube-system, and kube-public. You can also add a namespace, which should exist in the cluster.

     If you select namespaces, permission policies take effect only on namespace resources, not cluster resources. For details about namespace and cluster resources, see Kubernetes Resource Objects.

   • Set Permissions: Select permissions from the drop-down list box. You can select multiple permissions at a time to batch grant permissions.

   In this example, select default for namespace and the readonly permission.

   If different namespaces are associated with different permission policies (for example, the default namespace is associated with the readonly permission policy and the development namespace is associated with the develop permission policy, you can click to add multiple relationships of permission granting.

4. Click OK.

   If you need to update the permission policy of the fleet, select the namespace and permission again using the preceding method.

Verifying the Permission Setting

Log in to the console as the newly created readonly_useruser and check whether the permission takes effect. The following uses an attached cluster as an example.

• Go to the attached cluster of the fleet and choose Resources > Workloads. If you can view the workloads of the default namespace but a message is displayed indicating that you do not have the permission for viewing workloads of other namespaces, the read-only permission has taken effect.
• Go to the attached cluster of the fleet and choose Resources > Workloads. Switch to the default namespace, and click Create Workload in the upper right corner. If a message is displayed indicating that you do not have the permission, the read-only permission has taken effect.