前言

看图，如下：

左下角的Pod需要访问k8s的资源，需要通过中间 apiserver 的认证、授权、准入控制 三个东西，这就需要一个serviceAccount，帮助它完成这个过程，才能访问k8s的资源。

一、每个命名空间都会一个有个serviceAccount

serviceAccount的作用是是给集群内pod里面的进程使用，用来访问集群内的资源，所以每个ns都会一个一个名称为default的命名空间，如下：

同时也可以自定义serviceAccount

为什么使用了serviceAccount就可以认证集群，因为每个sa下面都会拥有的一个加密的token，使用 secrets 存储，

这个secrets(加密token)本质上等同于userAccount的认证集群的三种凭证文件：X509客户端证书，静态token文件，静态账号密码文件。

既然这个ns-monitor命名空间下，有这样一个名为default的serviceAccount，我们就来使用一下这个serviceAccount，如下，新建一个Pod使用这个serviceAccount：

查看一下正在运行的 kind: daemonSet 资源 node-exporter，但是没有找到对serviceAccount的引用，因为任何拉取镜像的运行资源 (pod replicaset deployment statefulset deamonset job/cronjob) ，对于serviceAccount(serviceAccount类型的secrets)的引用，都是在底层的Pod里面的，所以要看pod，如下：

查看daemonset底层运行的pod，找到了对于serviceAccount类型type的secrets的引用，如下：

至此，这个名为default的serviceAccount就被pod使用了，这个pod使用了这个serviceAccount(其实是加载了这个serviceAccount关联的secrets)之后，就可以访问k8s集群内的资源。

那么，为什么pod启动通过volume加载了type类型为serviceAccount的secrets之后，就可以访问到k8s里面资源呢？我们看一下这个secrets到底存储的哪些数据data （secrets类似一个加密的configmap，可以简单理解为配置文件，里面存储了数据）

一个 secrets (type:serviceAccount) 里面包含的data是：加密的ca.crt、加密的namespace、加密的token，如下：

二、Secret三种type

Kubernetes提供了Secret来处理敏感信息，目前Secret的类型有3种，通过type属性指定：
Opaque(default): 任意字符串，使用base64编码存储信息，可以通过base64 --decode解码获得原始数据，因此安全性弱。
kubernetes.io/service-account-token: 作用于ServiceAccount，就是上面说的。
kubernetes.io/dockercfg: 作用于Docker registry，用户下载docker镜像认证使用。

2.1 Opaque(default)

Opaque类型的Secret的value为base64位编码后的值

2.1.1 Secret创建的两种方式

创建方式1：从文件中创建Secret

echo -n "admin" > ./username.txt
echo -n "1f2d1e2e67df" > ./password.txt

kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt

kubectl get secret

演示如下：

创建方式2：使用yaml文件创建Secret

(1)对数据进行64位编码

echo -n 'admin' | base64
echo -n '1f2d1e2e67df' | base64

(2)定义mysecret.yaml文件

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm

(3)根据yaml文件创建资源并查看

kubectl create -f ./secret.yaml
kubectl get secret
kubectl get secret mysecret -o yaml

演示如下：

2.1.2 Secret使用的两种方式

• 以Volume方式

• 以环境变量方式

使用方式1：以Volume方式使用Secret

kubectl apply -f mypod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    secret:
      secretName: mysecret

kubectl exec -it pod-name bash  ## 进去
ls /etc/foo
cat /etc/foo/username
cat /etc/foo/password

以Volume方式使用Secret，演示如下：

使用方式2：将Secret设置为环境变量

kubectl get secret mysecret -o yaml
vi secret-env-pod.yaml
kubectl apply -f secret-env-pod.yaml
kubectl get pod 
kubectl exec -it 具体pod名称 bash

apiVersion: v1
kind: Pod
metadata:
  name: secret-env-pod
spec:
  containers:
  - name: mycontainer
    image: redis
    env:
      - name: SECRET_USERNAME
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: username
      - name: SECRET_PASSWORD
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: password
  restartPolicy: Never

演示如下：

小结：secret两种方式被创建，创建完之后都可以被pod里面的container去使用

使用的方式：环境变量(container下面的env)、参数(container下面的args)、volume目录挂载(container下面的volume)

2.2 kubernetes.io/service-account-token

一般来说，k8s资源有不同的kind。
configmap secret user usergroup serviceAccount 不需要运行具体的程序，所以不需要 image: 属性拉取镜像
pod replicasets deployment statefulset daemonset job/cronjob 需要运行具体的程序，所以需要 image: 属性拉取镜像

另外，从来没有一种kind: UserAccount类型的资源

2.3 kubernetes.io/dockercfg

在需要安全验证的环境中拉取镜像的时候，需要通过用户名和密码。

apiVersion: v1
kind: Secret
metadata:
  name: myregistrykey
  namespace: awesomeapps
data:
  .dockerconfigjson: UmVhbGx5IHJlYWxseSByZWVlZWVlZWVlZWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx5eXl5eXl5eXl5eXl5eXl5eXl5eSBsbGxsbGxsbGxsbGxsbG9vb29vb29vb29vb29vb29vb29vb29vb29vb25ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==
type: kubernetes.io/dockerconfigjson

或者直接通过命令创建

kubectl create secret docker-registry myregistrykey \
 --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER \
 --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL

接下来拉取镜像的时候，就可以使用了

apiVersion: v1
kind: Pod
metadata:
  name: foo
  namespace: awesomeapps
spec:
  containers:
    - name: foo
      image: janedoe/awesomeapp:v1
  imagePullSecrets:
    - name: myregistrykey

其实本质上还是kubelet把这个认证放到了docker的目录下面，如下：

cat ~/.docker/config.json 
{
    "auths": {
        "10.39.0.118": {
            "auth": "Y2hlbm1vOmNtMTM4MTE2NjY3ODY="
        },
        "10.39.0.12:5000": {
            "auth": "dXNlcjAxOjEyMzQ1YQ=="
        },
        "http://10.39.0.12:5000": {
            "auth": "dXNlcjAxOjEyMzQ1YQ=="
        }
    }
}

三、自定义ServiceAccount再分析一遍

3.1 Service Account创建

#查看serviceaccount资源
[root@k8s-master ~]# kubectl get sa     
NAME      SECRETS   AGE
default   1         7d19h
#创建一个名为admin的serviceaccount资源
[root@k8s-master ~]# kubectl create serviceaccount admin    
serviceaccount/admin created
#查看serviceaccount资源
[root@k8s-master ~]# kubectl get sa     
NAME      SECRETS   AGE
admin     1         7s
default   1         7d19h
#查看serviceaccount资源admin的详细信息，可以看出已经自动生成了一个Tokens：admin-token-lc826
[root@k8s-master ~]# kubectl describe sa/admin    
Name:                admin
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   admin-token-lc826
Tokens:              admin-token-lc826
Events:              <none>
#查看secret，可以查看也生成了一个admin-token-lc826的secret资源
[root@k8s-master ~]# kubectl get secret    
NAME                  TYPE                                  DATA   AGE
admin-token-lc826     kubernetes.io/service-account-token   3      50s
......

3.2 在Pod中使用自定义的service account

每个Pod对象均可附加其所属名称空间中的一个Service Account资源，且只能附加一个。不过，一个Service Account资源可由所属名称空间中的多个Pod对象共享使用。创建Pod时，通过“spec.serviceAccountName”进行定义。示例如下：

[root@k8s-master manfests]# vim pod-sa-demo.yaml    #编辑资源清单文件
apiVersion: v1
kind: Pod
metadata:
  name: pod-sa-demo
  namespace: default
  labels:
    app: myapp
    tier: frontend
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    ports:
    - name: http
      containerPort: 80
  serviceAccountName: admin    #指定serviceAccount资源名称
  
[root@k8s-master manfests]# kubectl apply -f pod-sa-demo.yaml 
pod/pod-sa-demo created
[root@k8s-master manfests]# kubectl get pods -l app=myapp
NAME          READY   STATUS    RESTARTS   AGE
pod-sa-demo   1/1     Running   0          9s
[root@k8s-master manfests]# 
[root@k8s-master manfests]# kubectl describe pods/pod-sa-demo
Name:         pod-sa-demo
Namespace:    default
......
Volumes:
  admin-token-lc826:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  admin-token-lc826      #这里可以看出挂载token就是上面创建的sa所生成的那个
    Optional:    false
......

总结

总结一下，梳理出ServiceAccount服务账号一条线，kind: serviceAccount 作为k8s集群内的一类资源，每个命名空间都会一个名为default的默认的serviceAccount，默认不指定的情况下，这个命名空间下所有的pod都是使用名为default的默认的serviceAccount，这个serviceAccount是通过secrets存储的，这个secrets等效加密的configmap，就是配置文件一类东西，type是serviceAccount，包含的data是：加密的namespace、加密的ca.crt、加密的token，有了这些data，这个命名空间下的Pod在启动的时候通过volume挂盘的方式，将secrets加载到整个Pod里面，Pod的进程就可以访问k8s集群内的资源了。

然后，这种用在serviceAccount上的secrets只是一种类型type的secrets，secrets还有两种其他类型type的，普通字符串和imagePullSecrets，顺便一起学习了。

最后，还可以自定义ServiceAccount，再重新分析一遍，加深理解。

这里面有一个难以搞清的概念，那就是对于一一对应关系的serviceAccount和secrets，其实不用分的这么清楚，serviceAccount是一个账号，secrets是这个账号里面存储的数据，然后一一绑定在一起，甚至简单点理解，两个东西作为一个整体，任何是一个东西都可以(因为很难分开)。