譯者：Nancy

這是對Service Accounts的叢集管理指南

User Accounts和Service Accounts

基於以下原因，Kubernetes區分了User Accounts和Service Accounts：

• User Accounts針對人，Service Accounts針對執行在Pod的程序；
• User Accounts是全域性的，其名字必須在一個叢集的所有Namespace中是唯一的。未來的使用者資源將不被命令，但是Service Accounts是可以被命名的。
• 通常情況下，叢集的User Accounts可以從一個企業資料庫同步。在企業資料庫中，新建的賬戶需要特殊許可權，而且繫結到複雜業務流程。新建Service Accounts可以更加輕量級，允許叢集使用者為特殊任務建立Service Accounts（比如，最小許可權規則）。
• 對人類和Service Accounts的稽核注意事項是不同的。
• 複雜系統的配置包含對系統元件的各種Service Accounts的定義。因為Service Accounts
• 可以建立ad-hoc，可以命名，配置是行動式的。

Service Accounts自動化

三個獨立的元件合作實現對Service Accounts的自動化。

• Service賬戶Admission Controller
• Token控制器
• Service Accounts控制器

Service Accounts Admission Controller

Pod的修改是Admission Controller外掛實現的，該外掛是apiserver的一部分。外掛的建立和更新，會同步修改Pod。當外掛狀態是active（大多版本中，預設是active），建立或者修改Pod會遵循以下流程：

1. 如果該Pod沒有ServiceAccount集，將ServiceAccount設為default
2. ServiceAccount必須有存在的Pod引用，否則拒絕該ServiceAccount
3. 如果該Pod不包含任何ImagePullSecrets，然後該ServiceAccount的ImagesPullSecrets會被加入Pod。
4. 新增一個volume到該Pod，包含API訪問的令牌。
5. 新增一個volume到該Pod的每一個容器，掛載在/var/run/secrets/kubernetes.io/serviceaccount

Token Controller

TokenController做為controller-manager的一部分非同步執行。

• 檢查serviceAccount的建立，並且建立一個關聯的Secret，允許API訪問。
• 檢查serviceAccount的刪除，並且刪除所有相關ServiceAccountToken Secrets
• 檢查額外Secret，確保引用的ServiceAccount的存在，並且如果有必要則新增一個Token到該Secret。
• 檢查Secret的刪除，如果有必要，從相關的ServiceAccount中移除參考資訊。

建立額外的API Token

一個控制循壞要確保每一個Service Accounts存在一個API Token。為一個Service Accounts建立一個額外的API Token，型別是ServiceAccountToken，含有一個註釋去引用到對應的個Service Accounts。該控制器使用如下的Token去更新：

secret.json:
{
"kind": "Secret",
"apiVersion": "v1",
"metadata": {
"name": "mysecretname",
"annotations": {
"kubernetes.io/service-account.name": "myserviceaccount"
}
},
"type": "kubernetes.io/service-account-token"
}
kubectl create -f ./secret.json
kubectl describe secret mysecretname

刪除、廢棄一個個Service Accounts Token

kubectl delete secret mysecretname

Service Account Controller

Service Account Controller管理Namespace中的ServiceAccount，確保每一個“default”的ServiceAccount存在於每一個活動空間中。