takeaway

The last article covered the RBAC authorization mode for K8S, so today we’ll take a quick look at ServiceAccount.

Introduction to the

K8s creates two independent account systems. The reasons are as follows:

(1) The User Account is used by the User, while the Service Account is used by the process in the Pod, which faces different objects

(2) The User Account is global, while the Service Account belongs to a specific Namespace

(3) The User Account is synchronized with the back-end User database. Creating a new User usually requires a set of complex business processes to achieve, and the creation of Service Account requires a very lightweight implementation. The cluster administrator can easily create a Service Account for some specific tasks

(4) For a complex system, multiple components usually have the configuration information of various accounts. Service Account is isolated from Namespace, which allows one-to-one definition of components and good portability.

The Controller Manager creates two security-related controllers, the ServiceAccount Controller and the Token Controller. The ServiceAccount Controller listens for ServiceAccount events and Namespace events. If there is no default ServiceAccount in a Namespace, The Service Account creates a default Service Account for the Namespace.

If the Controller Manager process is started with API Service private key (service-accountprivate-key-file parameter), then the Controller Manager will create Token Controller. The Token Controller also listens for Service Account events.

Kube-apiserver: Kube-Apiserver: Kube-Apiserver: Kube-Apiserver: Kube-Apiserver

--admission_control=ServiceAccount
Copy the code

If Pod requests are added or modified, the Service Account access controller will verify whether the Service Account in Pod is valid:

(1) If the spec.serviceAccount field is not set, Kubernetes will specify a Service Account named default for it by default.

(2) If spec.serviceAccountName is specified but not default, the Pod operation fails if the Service Account does not exist.

(3) If the Pod does not specify ImagePullSecrets, the Service Account’s ImagePullSecrets specified by the spec.serviceAccount field will be automatically added to the Pod.

(4) Add a special Volume to Pod that contains the Token from ServiceAccount Secret. And the Volume is mounted to the Pod all the containers in the specified directory (/ var/run/secrets/kubernetes. IO/serviceaccount).

ServiceAccount

ServiceAccount is an account that provides the necessary identification for processes running inside a Pod.

Those who have done business systems know that there is a definition called Role in the system. A Role is a collection of privileges, and the Role mentioned in the previous article is this Role, and the ServiceAccount is equivalent to owning an account of a Role, which means owning some privileges.

To ensure the security of the K8S cluster, API Server authenticates the clients. Kubernetes = Kubernetes; Kubernetes = Kubernetes; Kubernetes = Kubernetes; When Pod calls API Server, it passes a Token string in the Http Header. This is similar to the Http Token authentication method mentioned above, with the following differences:

(1) Token content comes from a file (file name Token) in the path specified by Pod. A JWT Secret is specified to be generated by the Kubernetes Controller process signed with API Server’s private key (–service-account-private-zkey-file).

(2) After the CONNECTION with the API Server is established through HTTPS, the SYSTEM uses a CA certificate (file name: ca.crt) in the Pod directory to verify the certificate sent by the API Server and whether it is a valid certificate signed by the CA certificate.

(3) After receiving the Token, the API Server uses its own private key (service-accountkey-file) to verify the Token. If this parameter is not specified, the TLS-private-key-file parameter is used by default.

The above certification that involved in the process of Pod in the following three files: token, ca. CRT, namespace, all three files in the/run/secrets/kubernetes IO/serviceaccount directory

These three files are called Kubernetes Secret objects because they play a similar role in the Pod process and API Server authentication. Secret belongs to the Service Account resource object. A Service Account object can contain multiple Secret objects that are used for authentication activities for different purposes.

A Secret also has these three things:

View details about the Service Account

kubectl describe serviceaccounts
Copy the code

See the Secret

kubectl get secrets
Copy the code

In each Namespace there is a default ServiceAccount object named Default. Inside this ServiceAccount there is a Secret named Tokens that can be mounted into Pod as a Volume. This Secret will be automatically mounted to the Pod directory to assist in Pod process authentication when accessing API Server.

A ServiceAccount can contain multiple Secrets

Among them

Tokens Secret Is a Secret that accesses the API Server.

(2) Secret named imagePullSecrets is used for the authentication process when downloading container images. Usually, the image library runs in Insecure mode, so this is empty

(3) Other Secret user-defined by the user for the user process.

If a Pod is defined without the spec.serviceAccountName attribute, it defaults to default and can be specified as follows:

apiVersion: v1
kind: Pod
metadata:
  name: pod
spec:
  containers:
  - name: podtest
    image: nginx
  serviceAccountName: myServiceAccount
Copy the code

Create ServiceAccount

apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard-admin
  namespace: kube-system
Copy the code

Bind this ServiceAccount to ClusterRole:

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: kubernetes-dashboard-admin
  labels:
    k8s-app: kubernetes-dashboard
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: kubernetes-dashboard-admin
  namespace: kube-system
Copy the code

This gives ServiceAccount ClusterRole rights

Use ServiceAccount in Pod

apiVersion: v1
kind: Pod
metadata:
  name: pod
  namespace: kube-system
spec:
  containers:
  - name: podtest
    image: nginx
  serviceAccountName: kubernetes-dashboard-admin
Copy the code

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

I’m Liusy, a programmer who likes to work out.

Welcome to pay attention to wechat public number [ancient pseudo god], exchange Java technology and fitness, get more dry goods, get Java advanced dry goods, get the latest factory interview materials, become Java god together.

Here we go. Keep an eye on it.