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:

    In this example, the permission rules include the read-only permission (get/list/watch) of pods in the test namespace, and the read (get/list/watch) and create permissions of deployments.

    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 5 to 7 to write the user information to the configuration file.

  4. Manually create a token that is valid for a long time for ServiceAccount.

    vi my-sa-token.yaml
    The content is as follows:
    apiVersion: v1
kind: Secret
metadata:
  name: my-sa-token-secret
  namespace: test
  annotations:
    kubernetes.io/service-account.name: my-sa
type: kubernetes.io/service-account-token

    Create a token:

    kubectl create -f my-sa-token.yaml

  5. Configure the cluster information.

    1. Decrypt the ca.crt file in the secret and export it.
    kubectl get secret my-sa-token-secret -n test -oyaml |grep ca.crt: | awk '{print $2}' |base64 -d > /home/ca.crt
    1. Set a cluster access mode. test-arm specifies the cluster to be accessed. https://192.168.0.110:5443 specifies the apiserver IP address of the cluster. /home/test.config specifies 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://192.168.0.110: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://192.168.0.110: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.

    By default, the apiserver IP address of the cluster is a private IP address. After an EIP is bound, you can use the public network IP address to access the apiserver.

  6. 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-secret -n test | awk '/token:/{print $2}')
    1. Set the cluster user ui-admin.
    kubectl config set-credentials ui-admin --token=$token --kubeconfig=/home/test.config

  7. Configure the context information for cluster authentication access. ui-admin@test specifies the context name.

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

  8. Configure 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 7. The user must ensure that the host can access the API server address of the cluster. When performing step 8 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.

Parent topic: Permission