Overview

TKE supports managing sub-accounts authorization through the Authorization Management feature in the console, or customizing YAML ([RBAC Authorization](https://kubernetes.io/en/docs/reference /access-authn-authz/rbac/)) to meet more personalized authorization requirements. The Kubernetes RBAC authorization instructions and principles are as follows:

• Permission objects (Role or ClusterRole): uses apiGroups, resources, and verbs to define permissions, including:
  • Role permission object: a Role always sets permissions within a particular namespace.
  • ClusterRole permission object: a ClusterRole can be reused for multiple namespace authorizations (Rolebinding) or for the entire cluster authorization (ClusterRoleBinding).
• Authorization object (Subjects): the subjects for granting permissions, including three types of subjects: User, Group, and ServiceAccount.
• Permission Binding (Rolebinding or ClusterRoleBinding): combines and binds the permission objects and authorization objects, including:
  • Rolebinding: permission binding for a specific namespace.
  • ClusterRoleBinding: permission binding for the entire cluster.

As shown in the figure above, Kubernetes RBAC authorization mainly provides the following three permission binding methods. This document describes how to use these three permission binding methods to achieve user authorization management.

Note：

Starting from Kubernetes RBAC v1.9, you can also create ClusterRole by using aggregationRule to combine with other ClusterRoles. For more information, see Aggregated ClusterRoles.

Directions

Permission binding for a single namespace

This method is mainly used to bind related permissions of a certain namespace for a certain user, and is suitable for scenarios that require refined permissions. For example, developers, testers, and OPS personnel can only operate on resources in their respective namespaces. The following directions describe how to implement permission binding for a single namespace in TKE.

1. Use the following Shell script to create a test namespace and a test user of ServiceAccount type, and set up cluster access credential (Token) authentication, as shown below:

   USERNAME='sa-acc' # Set the test account name
   NAMESPACE='sa-test' # Set the test namespace name
   CLUSTER_NAME='cluster_name_xxx' # Set the test cluster name
   # Create the test namespace
   kubectl  create namespace ${NAMESPACE} 
   # Create the test ServiceAccount account
   kubectl create sa ${USERNAME} -n ${NAMESPACE} 
   # Obtain the Secret token resource name automatically created by the ServiceAccount account
   SECRET_TOKEN=$(kubectl get sa ${USERNAME} -n ${NAMESPACE} -o jsonpath='{.secrets[0].name}')
   # Obtain the plaintext Token of secrets
   SA_TOKEN=$(kubectl get secret ${SECRET_TOKEN} -o jsonpath={.data.token} -n sa-test | base64 -d)
   # Set an access credential of token type using the obtained plaintext token information
   kubectl config set-credentials ${USERNAME} --token=${SA_TOKEN}
   # Set the context entries for accessing the cluster
   kubectl config set-context ${USERNAME} --cluster=${CLUSTER_NAME} --namespace=${NAMESPACE} --user=${USERNAME}

2. Run the command kubectl config get-contexts to view the generated contexts entries, as shown below:
   
3. Create a Role permission object resource file “sa-role.yaml”, as shown below:

   kind: Role
   apiVersion: rbac.authorization.k8s.io/v1
   metadata: 
    namespace: sa-test # Specify the Namespace
    name: sa-role-test
   rules: # Set the permission rule
   - apiGroups: ["", "extensions", "apps"]
   resources: ["deployments", "replicasets", "pods"]
   verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

4. Create a RoleBinding object resource file “sa-rb-test.yaml”. The following permission binding indicates that the sa-acc user of ServiceAccount type has sa-role-test (Role type) permissions in the sa-test namespace, as shown below:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata: 
    name: sa-rb-test
    namespace: sa-test 
   subjects: 
   - kind: ServiceAccount
   name: sa-acc
   namespace: sa-test # The Namespace where ServiceAccount locates 
   apiGroup: ""  # The default apiGroup is rbac.authorization.k8s.io.
   roleRef: 
   kind: Role
   name: sa-role-test
   apiGroup: ""  # The default apiGroup is rbac.authorization.k8s.io.

5. From the verification result in the following figure, you can find that when the Context is sa-context, the default namespace is sa-test, and it has the permissions configured in the sa-role-test (Role) object under the sa-test namespace, but it has no permission under the default namespace.
   

Permission binding for multiple namespaces by reusing the cluster permission object

This method is mainly used to grant users the same permissions in multiple namespaces. It is suitable for scenarios where a permission template is used to bind authorizations for multiple namespaces. For example, developers need to bind the same resource operations permission in multiple namespaces. The following directions describe how to implement permission binding for multiple namespaces by reusing cluster permission object in TKE.

1. Use the following Shell script to create an user authenticated with X509 self-signed certificate, approve the CSR and the certificate as trustworthy, and set the cluster resource access credential Context, as shown below:

   USERNAME='role_user' # Set the user name that you want to create
   NAMESPACE='default' # Set the test namespace name
   CLUSTER_NAME='cluster_name_xxx' # Set the test cluster name
   # Use Openssl to generate a self-signed certificate key
   openssl genrsa -out ${USERNAME}.key 2048
   # Use Openssl to generate a self-signed CSR file, with CN indicating the user name and O indicating the group name.
   openssl req -new -key ${USERNAME}.key -out ${USERNAME}.csr -subj "/CN=${USERNAME}/O=${USERNAME}" 
   # Create a Kubernetes CSR
   cat <<EOF | kubectl apply -f -
   apiVersion: certificates.k8s.io/v1beta1
   kind: CertificateSigningRequest
   metadata:
      name: ${USERNAME}
   spec:
      request: $(cat ${USERNAME}.csr | base64 | tr -d '\n')
      usages:
      - digital signature
      - key encipherment
      - client auth
   EOF
   # Approve the certificate as trustworthy
   kubectl certificate approve ${USERNAME}
   # Obtain the self-signed certificate CRT
   kubectl get csr ${USERNAME} -o jsonpath={.status.certificate} | base64 --decode > ${USERNAME}.crt
   # Set the cluster resource access credentials (X509 certificate)
   kubectl config set-credentials ${USERNAME} --client-certificate=${USERNAME}.crt --client-key=${USERNAME}.key
   # Set Context cluster, default Namespace, etc.
   kubectl config set-context  ${USERNAME} --cluster=${CLUSTER_NAME} --namespace=${NAMESPACE} --user=${USERNAME}

2. Create a ClusterRole object resource “test-clusterrole.yaml”, as shown below:

   kind: ClusterRole
   apiVersion: rbac.authorization.k8s.io/v1
   metadata: 
    name: test-clusterrole
   rules: 
   - apiGroups: [""]
   resources: ["pods"]
   verbs: ["get", "watch", "list", "create"]

3. Create a RoleBinding object resource file “clusterrole-rb-test.yaml”. The following permission binding indicates that the user role_user with the self-signed certificate authentication has the test-clusterrole (ClusterRole type) permission in the default namespace, as shown below:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata: 
    name: clusterrole-rb-test
    namespace: default 
   subjects: 
   - kind: User
   name: role_user
   namespace: default # The Namespace where User locates 
   apiGroup: ""  # The default apiGroup is rbac.authorization.k8s.io.
   roleRef: 
   kind: ClusterRole
   name: test-clusterrole
   apiGroup: ""  # The default apiGroup is rbac.authorization.k8s.io.

4. From the verification result in the figure below, you can find that when the Context is role_user, the default namespace is “default”, and it has the permissions configured by the test-clusterrole permission object.
   
5. Create the second RoleBinding object resource file “clusterrole-rb-test2.yaml”. The following permission binding indicates that the user role_user with the self-signed certificate authentication has the test-clusterrole (ClusterRole type) permission in the default2 namespace.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata: 
    name: clusterrole-rb-test
    namespace: default2 
   subjects: 
   - kind: User
   name: role_user
   namespace: default # The Namespace where User locates 
   apiGroup: ""  # The default apiGroup is rbac.authorization.k8s.io.
   roleRef: 
   kind: ClusterRole
   name: test-clusterrole
   apiGroup: ""  # The default apiGroup is rbac.authorization.k8s.io.

6. From the verification result in the figure below, you can find that in the default2 namespace, role_user also has the permissions configured by test-clusterrole. So far, through the above steps, it has implemented the permission binding for the multiple namespaces by reusing the cluster permissions.
   

Permission binding for the entire cluster

This method is mainly used to bind permissions of all namespaces (cluster-scoped) for a user, and is suitable for cluster-scoped authorization scenarios, such as log collection permission, admin permission. The following directions describe how to use multiple namespaces in TKE to reuse cluster permission for authorization binding.

1. Create a ClusterRoleBinding object resource file “clusterrole-crb-test3.yaml”. The following permission binding indicates that the user role_user with the certificate authentication has the test-clusterrole (ClusterRole type) permission in the entire cluster.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata: 
    name: clusterrole-crb-test
   subjects: 
   - kind: User
   name: role_user
   namespace: default # The Namespace where User locates 
   apiGroup: ""  # The default apiGroup is rbac.authorization.k8s.io.
   roleRef: 
   kind: ClusterRole
   name: test-clusterrole
   apiGroup: ""  # The default apiGroup is rbac.authorization.k8s.io.

2. From the verification result in the figure below, you can find that after the YAML of permission binding is performed, role_user has the cluster-wide test-clusterrole permission.
   

Summary

Combined with Tencent Cloud access permission management and Kubernetes RBAC authorization mode, the authorization management feature in TKE console becomes simple and convenient, which can meet the permission management scenarios of most Tencent Cloud sub-accounts. The custom permission binding via YAML is more flexible and suitable for complex and personalized user permission management scenarios. Users can choose the permission management method based on the actual authorization requirements.