# Controlling Cluster Permissions

#### Scenario

This section describes how to control permissions on resources in a cluster, for example, allow user A to read and write application data in a namespace, and user B to only read resource data in a cluster.

#### Procedure

1. If you need to perform permission control on the cluster, select Enhanced authentication for Authentication Mode during cluster creation, upload your own CA certificate, client certificate, and client certificate private key (for details about how to create a certificate, see Certificates), and select I have confirmed that the uploaded certificates are valid. For details, see Table 1.

   - Upload a file smaller than 1 MB. The CA certificate and client certificate can be in .crt or .cer format. The private key of the client certificate can only be uploaded unencrypted.
   - The validity period of the client certificate must be longer than five years.
   - The uploaded CA certificate is used for both the authentication proxy and the kube-apiserver aggregation layer configuration. If the certificate is invalid, the cluster cannot be created.
2. Create a role using kubectl.

   The following example shows how to create a role and allow the role to read all pods in the default namespace. For details about the parameters, see the official Kubernetes documentation.

       kind: Role
       apiVersion: rbac.authorization.k8s.io/v1
       metadata:
         namespace: default
         name: pod-reader
       rules:
       - apiGroups: [""]
         resources: ["pods"]
         verbs: ["get", "watch", "list"]

3. Bind the role to a user by using kubectl.

   In the following example, the RoleBinding assigns the role of pod-reader in the default namespace to user jane. This policy allows user jane to read all pods in the default namespace. For details about the parameters, see the official Kubernetes documentation.

       kind: RoleBinding
       apiVersion: rbac.authorization.k8s.io/v1
       metadata:
         name: read-pods
         namespace: default
       subjects:
       - kind: User
         name: jane   #User name
         apiGroup: rbac.authorization.k8s.io
       roleRef:
         kind: Role
         name: pod-reader    #Name of the role that is created
         apiGroup: rbac.authorization.k8s.io

4. After a role is created and bound to a user, call a Kubernetes API by initiating an API request message where headers carry user information and the certificate uploaded during cluster creation. For example, to call the pod query API, run the following command:

   curl -k -H "X-Remote-User: jane" --cacert /root/tls-ca.crt --key /root/tls.key --cert /root/tls.crt https://192.168.23.5:5443/api/v1/namespaces/default/pods

   If 200 is returned, user jane is authorized to read pods in the cluster's default namespace. If 403 is returned, user jane is not authorized to read pods in the cluster's default namespace.

   To prevent the command execution failure, upload the certificate to the /root directory in advance.

   The parameter descriptions are as follows:

   - X-Remote-User: jane: The request header is fixed at X-Remote-User, and jane is the username.
   - tls-ca.crt: CA root certificate uploaded during cluster creation.
   - tls.crt: client certificate that matches the CA root certificate uploaded during cluster creation.
   - tls.key: client key corresponding to the CA root certificate uploaded during cluster creation.
   - 192.168.23.5:5443: address for connecting to the cluster. To obtain the address, perform the following steps:

     Log in to the CCE console. In the navigation pane, choose Resource Management > Clusters. Click the name of the cluster to be connected and obtain the IP address and port number from Internal API Server Address on the cluster details page.

     Figure 1 Obtaining the access address

   In addition, the X-Remote-Group header field, that is, the user group name, is supported. During role binding, a role can be bound to a group and carry user group information when you access the cluster.

Parent topic: Clusters