Configuring kubeconfig for Fine-Grained Management on Cluster Resources

Application Scenarios

By default, the kubeconfig file provided by CCE for users has permissions bound to the cluster-admin role, which are equivalent to the permissions of user root. It is difficult to implement refined management on users with such permissions.

Purpose

Cluster resources are managed in a refined manner so that specific users have only certain permissions (such as adding, querying, and modifying resources).

Precautions

Ensure that kubectl is available on your host. If not, download it from here (corresponding to the cluster version or the latest version).

Configuration Method

In the following example, only pods and Deployments in the test space can be viewed and added, and they cannot be deleted.

1. Set the service account name to my-sa and namespace to test.

   kubectl create sa my-sa -n test

   

2. Configure the role table and assign operation permissions to different resources.

   vi role-test.yaml

   The content is as follows:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     annotations:
       rbac.authorization.kubernetes.io/autoupdate: "true"
     labels:
       kubernetes.io/bootstrapping: rbac-defaults
     name: myrole
     namespace: test
   rules:
   - apiGroups:
     - ""
     resources:
     - pods
     verbs:
     - get
     - list
     - watch
   - apiGroups:
     - apps
     resources:
     - pods
     - deployments
     verbs:
     - get
     - list
     - watch
     - create

   Create a Role.

   kubectl create -f role-test.yaml

   

3. Create a RoleBinding and bind the service account to the role so that the user can obtain the corresponding permissions.

   vi myrolebinding.yaml

   The content is as follows:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: myrolebinding
     namespace: test
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: myrole
   subjects:
   - kind: ServiceAccount
     name: my-sa
     namespace: test

   Create a RoleBinding.

   kubectl create -f myrolebinding.yaml

   

   The user information is configured. Now perform 4 to 6 to write the user information to the configuration file.

4. Configure the cluster information.
   1. Use the sa name my-sa to obtain the secret corresponding to the sa. In the following example, my-sa-token-z4967 in the first column is the secret name.

   kubectl get secret -n test |grep my-sa

   

   2. Decrypt the ca.crt file in the secret and export it.

   kubectl get secret my-sa-token-5gpl4 -n test -oyaml |grep ca.crt: | awk '{print $2}' |base64 -d > /home/ca.crt

   3. Set the cluster access mode. test-arm indicates the cluster to be accessed, 10.0.1.100 indicates the IP address of the API server in the cluster (for details about how to obtain the IP address, see Figure 1), and /home/test.config indicates the path for storing the configuration file.
      • If the internal API server address is used, run the following command:

        kubectl config set-cluster test-arm --server=https://10.0.1.100:5443  --certificate-authority=/home/ca.crt  --embed-certs=true --kubeconfig=/home/test.config

      • If the public API server address is used, run the following command:

        kubectl config set-cluster test-arm --server=https://10.0.1.100:5443 --kubeconfig=/home/test.config --insecure-skip-tls-verify=true

      

   

   If you perform operations on a node in the cluster or the node that uses the configuration is a cluster node, do not set the path of kubeconfig to /root/.kube/config.

   The cluster API server address is an intranet API server address. After an EIP is bound to the cluster, the cluster API server address can also be a public API server address.

   Figure 1 Obtaining the internal or public API server address
   

5. Configure the cluster authentication information.
   1. Obtain the cluster token. (If the token is obtained in GET mode, run based64 -d to decode the token.)

   token=$(kubectl describe secret my-sa-token-5gpl4 -n test | awk '/token:/{print $2}')

   2. Set the cluster user ui-admin.

   kubectl config set-credentials ui-admin --token=$token --kubeconfig=/home/test.config

   

6. Configure the context information for cluster authentication. ui-admin@test is the context name.

   kubectl config set-context ui-admin@test --cluster=test-arm --user=ui-admin --kubeconfig=/home/test.config

   

7. Set the context. For details about how to use the context, see Verification.

   kubectl config use-context ui-admin@test --kubeconfig=/home/test.config

   

   

   If you want to assign other users the above permissions to perform operations on the cluster, provide the generated configuration file /home/test.config to the user after performing step 6. The user must ensure that the host can access the API server address of the cluster. When performing step 7 on the host and using kubectl, the user must set the kubeconfig parameter to the path of the configuration file.

Verification

1. Pods in the test namespace cannot access pods in other namespaces.

   kubectl get pod -n test --kubeconfig=/home/test.config

   

2. Pods in the test namespace cannot be deleted.

   

Further Readings

For more information about users and identity authentication in Kubernetes, see Authenticating.