tencent cloud

Feedback

Customizing RBAC Authorization in TKE

Last updated: 2024-12-13 21:12:47
    TKE allows you to manage the general authorization of sub-accounts by using the authorization management feature in the console and customize your authorization by using a custom YAML (Using RBAC Authorization). Kubernetes RBAC authorization description and principle are as shown below:
    Permission objects (Role or ClusterRole): Use apiGroups, resources, and verbs to define permissions, including:
    Role permission object: Used for a specific namespace.
    ClusterRole permission object: It can be reused for authorization in multiple namespaces (RoleBinding) or the entire cluster (ClusterRoleBinding).
    Authorization object (Subjects): The subjects for granting permissions, including three types of subjects: User, Group, and ServiceAccount.
    Permission binding (RoleBinding or ClusterRoleBinding): It combines and binds the permission objects and authorization objects, including:
    RoleBinding: Used for a specific namespace.
    ClusterRoleBinding: Used for the entire cluster.
    Kubernetes RBAC authorization mainly provides the following four permission binding methods. This document describes how to use them for user authorization management.
    Method
    Description
    RoleBinding references a Role object to grant Subjects resource permissions in a namespace.
    Different RoleBinding objects in multiple namespaces can reference the same ClusterRole object template to grant Subjects the same template permissions.
    ClusterRoleBinding references the ClusterRole template to grant Subjects permissions for the entire cluster.
    You can customize permissions, for example, grant a user the permission to log in to the TKE cluster in addition to the preset read-only permission.
    Note:
    In addition to the above methods, you can combine ClusterRole with other ClusterRoles by using aggregationRule on Kubernetes RBAC v1.9 or later. For more information, see Aggregated ClusterRoles.

    Method 1. Bind permissions in a namespace

    This method is mainly used to bind related permissions under a certain namespace for a certain user. It is suitable for scenarios that require refined permissions. For example, developers, testers, and Ops personnel can only manipulate resources in their respective namespaces. The following describes how to implement permission binding for a 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}')
    # Get the plaintext token of the 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 kubectl config get-contexts command to view the generated contexts as shown below:
    image-20201020105559159
    
    
    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 of the ServiceAccount
    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 as shown below, 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 permissions under the default namespace.
    image-20201020111456470
    
    

    Method 2. Reuse permission objects for binding in multiple namespaces

    This method is mainly used to grant the same permissions in multiple namespaces to a user. It is suitable for scenarios where a permission template is used to bind permissions in multiple namespaces. For example, you might want to bind the same resource operation permissions for DevOps personnel in multiple namespaces. The following describes how to reuse cluster permissions in multiple namespaces in TKE.
    1. Use the following shell script to create an user authenticated with X.509 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 username
    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, where `CN` indicates the username and `O` indicates 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 credential (X.509 certificate)
    kubectl config set-credentials ${USERNAME} --client-certificate=${USERNAME}.crt --client-key=${USERNAME}.key
    # Set the Context cluster and default namespace
    kubectl config set-context ${USERNAME} --cluster=${CLUSTER_NAME} --namespace=${NAMESPACE} --user=${USERNAME}
    2. Create a ClusterRole object resource file 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 role_user user with the self-signed certificate authentication has test-clusterrole (ClusterRole type) permissions 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 of the user
    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 as shown 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.
    image-20201020114653469
    
    
    5. Create the second RoleBinding object resource file clusterrole-rb-test2.yaml. The following permission binding indicates that the role_user user with the self-signed certificate authentication has test-clusterrole (ClusterRole type) permissions 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 of the user
    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 as shown below, you can find that in the default2 namespace, role_user also has the permissions configured by test-clusterrole. At this point, you have implemented permission reuse and binding in multiple namespaces.
    image-20201020114512915
    
    

    Method 3. Bind permissions in the entire cluster

    This method is mainly used to bind permissions of all namespaces for a user. It is suitable for cluster-wide authorization, such as log collection permission and 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 role_user user with the certificate authentication has test-clusterrole (ClusterRole type) permissions 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 of the user
    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 as shown below, you can find that after the YAML of permission binding is applied, role_user has the cluster-wide test-clusterrole permissions.
    image-20201020141737129
    
    

    Method 4. Customize permissions

    This section describes how to grant a user custom permissions as a cluster admin, including preset read-only permission and additional permission to log in to the TKE cluster.

    1. Authorize

    First, grant read-only permission to a specified user as instructed in Using Preset Identity Authorization.

    2. View user information in the RBAC

    View the information of the user bound to the read-only ClusterRoleBinding, which is to be bounded to the new ClusterRoleBinding. As shown below, you need to view the details in the ClusterRoleBinding object of the specified user.
    
    
    subjects:
    - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: 700000xxxxxx-1650879262 # The username of the specified user in RBAC. You need to get this information of the specified user.

    3. Create a ClusterRole

    Create a ClusterRole through YAML for a read-only user with TKE login permission as shown below:
    apiVersion: rbac.authorization.k8s.io/v1beta1
    kind: ClusterRole
    metadata:
    name: "700000xxxxxx-ClusterRole-ro" # ClusterRole name
    rules:
    - apiGroups:
    - ""
    resources:
    - pods
    - pods/attach
    - pods/exec # Pod login permission
    - pods/portforward
    - pods/proxy
    verbs:
    - create
    - get
    - list
    - watch

    4. Create a ClusterRoleBinding

    Create the YAML file of the ClusterRoleBinding for the specified user as shown below:
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRoleBinding
    metadata:
    name: "700000xxxxxx-ClusterRoleBinding-ro"
    roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: "700000xxxxxx-ClusterRole-ro" # Use the ClusterRole name in step 3
    subjects:
    - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: "700000xxxxxx-1650879262" # Use the user information in step 2

    Summary

    Combined with Tencent Cloud access permission management and Kubernetes RBAC authorization mode, the authorization management feature in the TKE console becomes simple and convenient, which can meet the permission management scenarios of most Tencent Cloud sub-accounts. The custom permission binding through YAML is more flexible and suitable for complex and personalized user permission control. You can choose a permission management method as needed.
    Contact Us

    Contact our sales team or business advisors to help your business.

    Technical Support

    Open a ticket if you're looking for further assistance. Our Ticket is 7x24 avaliable.

    7x24 Phone Support