In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-16 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >
Share
Shulou(Shulou.com)05/31 Report--
This article mainly explains "how to add users in Kubernetes cluster". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "how to add users in Kubernetes cluster".
Users in Kubernetes
There are two types of users (User) in K8S-- the service account (ServiceAccount) and the general user (User) ServiceAccount are managed by K8S, while User is usually managed externally, and K8S does not store user lists-- that is, adding / editing / deleting users are carried out externally and do not need to interact with K8S API. Although K8S does not manage users, when K8S receives an API request, it can recognize the user who made the request. All API requests to K8S need to be bound with identity information (User or ServiceAccount), which means that request permissions in the K8S cluster can be configured for User.
ServiceAccount is an internal resource of K8S, while User is independent of K8S. It can be seen from their nature:
User is usually used by people, while ServiceAccount is used by a service / resource / program.
User is independent of K8S, which means that User can act globally, can be recognized in any namespace, and needs to be globally unique.
As a resource within K8S, ServiceAccount exists in a certain namespace, and ServiceAccount with the same name in different namespaces is considered to be different resources.
K8S does not manage User, so the creation / editing / logout of User depends on external management mechanisms.
The added user here refers to the user in the general sense, that is, the user who exists outside the cluster and is the user of K8s.
In fact, it is not accurate to call it adding a user. The user already exists. All that is done here is to enable K8S to recognize the user and control the user's permissions within the cluster.
User authentication
Although K8S only relies on the user's first name, it is obviously unreasonable to request the API of K8S with only one name, so you still need to verify the identity of this user. In K8S, there are the following verification methods:
X509 client certificate client certificate verification is enabled by specifying-- client-ca-file=xxx option for API Server. API Server uses this ca file to verify the validity of the client certificate carried by the API request. Once the verification is successful, API Server will use the CN attribute in the client certificate Subject as the user name of this request.
Static token files enable bearer token authentication by specifying the-- token-auth-file=SOMEFILE option. The referenced file is a csv file containing token, user name and user ID. When a request is made for a csv file with Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269 header information, it can be verified by bearer token.
Static password files enable password authentication by specifying the-- basic-auth-file=SOMEFILE option. Similarly, when a referenced file is a csv file containing password, user name, and user ID, the Authorization header needs to be set to Basic BASE64ENCODED (USER:PASSWORD).
Only client-side authentication is described here.
Generate certificates for users
First, you need to create a private key for this user:
Openssl genrsa-out tom.key 2048
Then create a csr (Certificate signing request) file with this private key, in which we need to bring the user information (CN is the user name, O is the user group) in the subject, where the / O parameter can appear multiple times, that is, there can be multiple user groups:
Openssl req-new-key tom.key-out tom.csr-subj "/ CN=tom/O=MGM"
Find the CA certificate file of the K8S cluster (API Server). Its location depends on how the cluster is installed. Usually under the / etc/kubernetes/pki/ path, there will be two files, one is the CA certificate (ca.crt) and the other is the CA private key (ca.key). Issue a certificate to the user through the CA certificate of the cluster and the csr file created earlier:
Openssl x509-req-in tom.csr-CA / etc/kubernetes/pki/ca.crt-CAkey / etc/kubernetes/pki/ca.key-CAcreateserial-out tom.crt-days 365
The-CA and-CAkey parameters need to specify the location of the cluster CA certificate, and the-days parameter specifies the expiration time of the certificate, which is 365 days here.
Finally, save the certificate (tom.crt) and private key (tom.key), which will be used to validate the API request.
Add role-based access control (RBAC) for users
First create a role that has all permissions under the acp namespace:
Kind: RoleapiVersion: rbac.authorization.k8s.io/v1metadata: namespace: acp name: acp-adminrules:- apiGroups: ["*"] resources: ["*"] verbs: ["*"]
Bind the role to the user tom:
Kind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata: name: acp-admin-binding namespace: acpsubjects:- kind: User name: tom apiGroup: "" roleRef: kind: Role name: acp-admin apiGroup: ""
As shown in yaml, the RoleBinding resource creates a relationship between the Role-User, the roleRef node specifies the role referenced by the RoleBinding, and the subjects node specifies the receptor for this RoleBinding, which can be User or the ServiceAccount mentioned earlier, where only the user named tom is included. Reference: https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding
Configure users for kubectl
Now that we want to operate the cluster as tom through kubectl, we need to add the authentication information of tom to the configuration of kubectl, that is, ~ / .kube / config, and add the authentication information of user tom to the configuration of kubectl with the following command:
Kubectl config set-credentials tom-client-certificate=tom.crt-client-key=tom.key
After the addition is completed, you can see the addition in ~ / .kube / config:
Users:- name: tom user: client-certificate: / root/k8s/tom.crt client-key: / root/k8s/tom.key
Add a context configuration with the following command:
Kubectl config set-context tom-cluster=kubernetes-namespace=acp-user=tom
After the addition is completed, you can see the addition in ~ / .kube / config:
Contexts:- context: cluster: kubernetes namespace: acp user: tom name: tom
The context information configured by the current kubectl can also be found through the kubectl config get-contexts command:
[root@master1 k8s] # kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE* kubernetes-admin@kubernetes kubernetes kubernetes-admin tom kubernetes tom acp
Use the newly created context:
# method 1: switch contextkubectl config use-context tom# mode 2: use the contextkubectl-- context=tom for use outside the cluster
Encode the contents of tom.crt/tom.key in BASE64:
Cat tom.crt | base64-- wrap=0cat tom.key | base64-- wrap=0
Copy the obtained encoded text into the ~ / .kube / config file:
Contexts:- context: cluster: kubernetes namespace: acp user: tom name: tom users:- name: tom user: client-certificate-data:... Client-key-data:... At this point, I believe you have a deeper understanding of "how to add users in Kubernetes cluster". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!
Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.