Shulou(Shulou.com)06/01 Report--

This article mainly introduces the example analysis of Service Account and Secret in kubernetes, which is very detailed and has certain reference value. Friends who are interested must finish it!

One: Service Account and Secret data structure

Second: Service Account and Secret operating mechanism

The master node of 1.kubernetes consists of three parts, kube-apiserver,kube-scheduler and kube-controller-manager. Controller manager generates ServiceAccount controller and token controller according to the configuration information of apiserver (--admission-control and-- service-account-private-key-file).

2.ServiceAccount controller has been listening for ServiceAccount and Namespace events. If there is no default Service Account in a Namespace, then Service Account Controller creates a default (default) Service Account for that Namespace.

3.Token Controller also listens for Service Account events. If it is found that there is no corresponding Service Account Secret in the newly created Service Account, it will create a Token (JWT Token) with the API Server private key (--the file specified by service-account-private-key-file), and use the Token, CA certificate (this is API Server's CA public key certificate, derived from root-ca-file in the controller-manager configuration file) and Namespace name to generate a new Secret object. And put it into the Service Account just now. If the listening event is a delete Service Account event, all Secret associated with that Service Account are automatically deleted. In addition, the Token Controller object listens for Secret creation, modification, and deletion events at the same time, and handles them differently depending on the event.

After receiving the Token, 4.API Server uses its own private key (actually uses the private key specified by the parameter service-account-key-file in the apiserver configuration file. If this parameter is not set, it defaults to the parameter specified by tls-private-key-file, that is, its own private key) to validate the Token legally.

Three: related concepts of Service Account

1. The introduction of the concept of Service Account is based on a usage scenario in which processes running in pod need to call Kubernetes API and other services that are not Kubernetes API. Service Account is not for users of the kubernetes cluster, but for processes in pod. It provides the necessary authentication for pod.

two。 If kubernetes turns on ServiceAccount (apiserver configuration file), a default default service account will be created under each namespace.

3.ServiceAccount details

4. When creating a pod, if you do not specify a service account, the system automatically assigns a default service account to the pod under the namespace it is in.

a. If the spec.serviceAccount field is not set, Kubernetes defaults to its Serviceaccount named default

b. If the spec.serviceAccount field of Pod specifies a ServiceAccount other than default, and the ServiceAccount is not created beforehand, the Pod operation fails

c. If "ImagePullSecrets" is not specified in the Pod, then the "ImagePullSecrets" of the ServiceAccount specified in the sec.serviceAccount domain will be joined to the Pod

d. Add a new Volume to Pod, including the Token in the ServiceAccountSecret, and mount the Volume to the specified directory of all containers in the Pod (/ var/run/secrets/kubernetes.io/serviceaccount)

IV: concepts related to Secret

1.Secret solves the problem of configuring sensitive data such as passwords, token, keys, etc., without exposing these sensitive data to the mirror or Pod Spec. Secret can be used as Volume or environment variables.

There are three types of 2.Secret:

Service Account: used to access Kubernetes API, automatically created by Kubernetes, and automatically mounted to the / run/secrets/kubernetes.io/serviceaccount directory of Pod

Secret in Opaque:base64 format, used to store passwords, keys, etc.

Kubernetes.io/dockerconfigjson: used to store authentication information for private docker registry.

We can store the sensitive information of other systems through Secret, mount the Secret into Container in the way of Mount, and then obtain the sensitive information by accessing the files in the directory. When a Pod is created by API Server, API Server does not verify that the Secret referenced by that Pod exists. Once this Pod is called, kubelet will try to get the value of Secret. If Secret does not exist or cannot connect to API Server temporarily, kubelet will retry to get Secret at regular intervals. In order to use the updated secret, you must delete the old Pod and recreate a new Pod.

The above is all the content of the article "sample Analysis of Service Account and Secret in kubernetes". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

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.