在RBAC的部份我們有談到ServiceAccount，但是只是簡單帶過。今天我們來聊聊它吧～

User是使用者控制集群的帳號，而ServiceAccount就是外部服務來和集群做互動的帳號，而這些外部服務像是Prometheus或Jenkins都需要ServiceAccount。

每個集群都會存在一個叫做default的ServiceAccount，而且在每次產生Pod時，都預設會將其掛上。

我們來看看ServiceAccount的YAML吧：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-robot

如果要幫Pod指定ServiceAccount則可以加上serviceAccountName：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: build-robot
  automountServiceAccountToken: false

• automountServiceAccountToken：Pod指定ServiceAccount後，會預設自動Mount這個ServiceAccount的Token，如果不想要的話，可以在Pod或ServiceAccount的YAML中加入這一欄並設定false。

另外要提醒的是，Pod的更新必須要重建才可以完成，同理幫已經在運行的Pod加上ServiceAccount也是需要重建的。

早期版本中ServiceAccount的Token是沒有時效限制的，具有高風險性。

而在v1.22以後，mount token可以用以下方式：

volumes:
 - name: kube-api-access-6mtg8
   projected:
	   defaultMode: 420
		 sources:
     - serviceAccountToken:
				 expirationSeconds: 3607
         path: token

可以看到多了expirationSeconds來設定預設時效。

也可以幫Pod指定ServiceAccount並讓其自動mount上～

v1.24開始，建立ServiceAccount不會自動建立token，所以我們需要自己建立token並會在約1小時後到期失效。

我們可以直接透過指令建立：

kubectl create token dashboard-sa

也可以透過Secret來產生一組永不過期的token：

apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
  name: mysecretname
  annotations:
    kubernetes.io/service-account.name: dashboard-sa

用Secret的這種方法的前提是，我們已經建好ServiceAccount，才能再用Secret來輔助。

此種方法風險性極高，必須考慮是否有必要承擔這個風險才執行。

最近真的太忙了……先讓我撐完30天再來補完之前的吧……

參考資料

为 Pod 配置服务账号