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:
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.
Method | Description |
---|---|
Permission binding for a single namespace | RoleBinding references a Role object and grants Subjects the resource permission of a certain namespace. |
Permission binding for multiple namespaces by reusing the cluster permission object | Different RoleBinding in multiple namesspaces can reference the same ClusterRole object template to grant Subjects the same permissions as the template. |
Permission binding for the entire cluster | The ClusterRolleBinding references the ClusterRole template to grant Subjects the entire cluster permissions. |
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.
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.
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}
kubectl config get-contexts
to view the generated contexts entries, 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"]
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.
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.
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}
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: test-clusterrole
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list", "create"]
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.
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.
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.
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.
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.
Was this page helpful?