Adding users to a kubernetes cluster
Previously, we built a kubernetes cluster environment through ansible. The main requirement here is to add a user for daily management and limit it to the specified namespace. The following operation is performed:
Users in kubernetes
There are two types of users (User) in K8S - service accounts (ServiceAccount) and users in the ordinary sense (User). ServiceAccount is managed by K8S, while User is usually managed externally. K8S does not store user lists - that is, adding/editing/deleting users is done externally without interacting with the K8S API. Although K8S does not manage users, when K8S receives API requests, it can recognize the user who made the request. In fact, all API requests to K8S need to be bound to identity information (User or ServiceAccount), which means that the request permissions in the K8S cluster can be configured for the User
When kubernetes accepts user requests, it usually adopts three methods: client certificate, static token file, and static password file. Here we only introduce certificate verification.
Generate user certificate
Prepare the certificate to generate the csr file, and issue the certificate through the kubernetes ca. Usually the ca file path of the k8s api server is /etc/kubernetes/pki/. cicd-admin-key.pem (private key) and cicd-admin.pem (certificate) will be generated here. For details on how to generate csr, please refer to: https://wnote.com/post/linux-openssl-issue-private-certificate/
The user name passed in the csr file here is cicd-admin
|
|
User Authority Control (RBAC)
Create Role
There are two main roles in RBAC in k8s, ordinary roles (Role) and cluster roles (ClusterRole). ClusterRole is a special role
- Role belongs to a certain namespace; while ClusterRole belongs to the entire cluster, including all namespaces
- ClusterRole can grant cluster-wide permissions, such as node resource management, and can request resources in all namespaces (by specifying –all-namespaces). By default, K8S has a built-in ClusterRole named admin. In actual use, there is no need to create an admin Role
Create a role called cicd-admin in the cicd namespace:
Bind a user to a specified role
Subjects specifies the account type, which can be either User or service account. Here, the user cicd-admin is specified. RoleRef specifies the reference role of RoleBinding
Or you can bind through kubectl:
|
|
Or bind the user to the admin role of the default ClusterRole. If cicd-admin is bound to admin here, its permissions will only be limited to the cicd namespace
Client configuration
Set cluster parameters
Set client authentication parameters
Set context parameters
Set the default context
|
|
Client use
Overwrite the kubeconfig file to ~/.kube/config
|
|
At this point, the introduction of adding users to kubernetes and authorizing access to the k8s cluster has come to an end.