前言

看圖，如下：

左下角的Pod需要訪問k8s的資源，需要通過中間 apiserver 的認證、授權(quán)、準(zhǔn)入控制 三個東西，這就需要一個serviceAccount，幫助它完成這個過程，才能訪問k8s的資源。

一、每個命名空間都會一個有個serviceAccount

serviceAccount的作用是是給集群內(nèi)pod里面的進程使用，用來訪問集群內(nèi)的資源，所以每個ns都會一個一個名稱為default的命名空間，如下：

同時也可以自定義serviceAccount

為什么使用了serviceAccount就可以認證集群，因為每個sa下面都會擁有的一個加密的token，使用 secrets 存儲，

這個secrets(加密token)本質(zhì)上等同于userAccount的認證集群的三種憑證文件：X509客戶端證書，靜態(tài)token文件，靜態(tài)賬號密碼文件。

既然這個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關(guān)聯(lián)的secrets)之后，就可以訪問k8s集群內(nèi)的資源。

那么，為什么pod啟動通過volume加載了type類型為serviceAccount的secrets之后，就可以訪問到k8s里面資源呢？我們看一下這個secrets到底存儲的哪些數(shù)據(jù)data （secrets類似一個加密的configmap，可以簡單理解為配置文件，里面存儲了數(shù)據(jù)）

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

二、Secret三種type

Kubernetes提供了Secret來處理敏感信息，目前Secret的類型有3種，通過type屬性指定：
Opaque(default): 任意字符串，使用base64編碼存儲信息，可以通過base64 --decode解碼獲得原始數(shù)據(jù)，因此安全性弱。
kubernetes.io/service-account-token: 作用于ServiceAccount，就是上面說的。
kubernetes.io/dockercfg: 作用于Docker registry，用戶下載docker鏡像認證使用。

2.1 Opaque(default)

Opaque類型的Secret的value為base64位編碼后的值

2.1.1 Secret創(chuàng)建的兩種方式

創(chuàng)建方式1：從文件中創(chuàng)建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

演示如下：

創(chuàng)建方式2：使用yaml文件創(chuàng)建Secret

(1)對數(shù)據(jù)進行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)根據(jù)yaml文件創(chuàng)建資源并查看

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

演示如下：

2.1.2 Secret使用的兩種方式

• 以Volume方式

• 以環(huán)境變量方式

使用方式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設(shè)置為環(huán)境變量

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

演示如下：

小結(jié)：secret兩種方式被創(chuàng)建，創(chuàng)建完之后都可以被pod里面的container去使用

使用的方式：環(huán)境變量(container下面的env)、參數(shù)(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

在需要安全驗證的環(huán)境中拉取鏡像的時候，需要通過用戶名和密碼。

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

或者直接通過命令創(chuàng)建

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

其實本質(zhì)上還是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創(chuàng)建

#查看serviceaccount資源
[root@k8s-master ~]# kubectl get sa     
NAME      SECRETS   AGE
default   1         7d19h
#創(chuàng)建一個名為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的詳細信息，可以看出已經(jīng)自動生成了一個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對象共享使用。創(chuàng)建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就是上面創(chuàng)建的sa所生成的那個
    Optional:    false
......

總結(jié)

總結(jié)一下，梳理出ServiceAccount服務(wù)賬號一條線，kind: serviceAccount 作為k8s集群內(nèi)的一類資源，每個命名空間都會一個名為default的默認的serviceAccount，默認不指定的情況下，這個命名空間下所有的pod都是使用名為default的默認的serviceAccount，這個serviceAccount是通過secrets存儲的，這個secrets等效加密的configmap，就是配置文件一類東西，type是serviceAccount，包含的data是：加密的namespace、加密的ca.crt、加密的token，有了這些data，這個命名空間下的Pod在啟動的時候通過volume掛盤的方式，將secrets加載到整個Pod里面，Pod的進程就可以訪問k8s集群內(nèi)的資源了。

然后，這種用在serviceAccount上的secrets只是一種類型type的secrets，secrets還有兩種其他類型type的，普通字符串和imagePullSecrets，順便一起學(xué)習(xí)了。

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

這里面有一個難以搞清的概念，那就是對于一一對應(yīng)關(guān)系的serviceAccount和secrets，其實不用分的這么清楚，serviceAccount是一個賬號，secrets是這個賬號里面存儲的數(shù)據(jù)，然后一一綁定在一起，甚至簡單點理解，兩個東西作為一個整體，任何是一個東西都可以(因為很難分開)。