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.
- Set the service account name to my-sa and namespace to test.
kubectl create sa my-sa -n test
- 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
- 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.
- Configure the cluster information.
- 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
- 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
- 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 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 the internal API server address is used, run the following command:
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.
- Configure the cluster authentication information.
- 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}')
- Set the cluster user ui-admin.
kubectl config set-credentials ui-admin --token=$token --kubeconfig=/home/test.config
- 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
- 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
- Pods in the test namespace cannot access pods in other namespaces.
kubectl get pod -n test --kubeconfig=/home/test.config
- Pods in the test namespace cannot be deleted.
Further Readings
For more information about users and identity authentication in Kubernetes, see Authenticating.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot