所有的 kubernetes 叢集中賬戶分為兩類，Kubernetes 管理的 serviceaccount(服務賬戶) 和 useraccount（使用者賬戶）。基於角色的訪問控制（“RBAC”）使用“rbac.authorization.k8s.io”API 組來實現授權控制，允許管理員通過Kubernetes API動態配置策略。
API Server 內部通過使用者認證後，然後進入授權流程。對合法使用者進行授權並且隨後在使用者訪問時進行鑑權，是許可權管理的重要環節。
在 kubernetes 叢集中，各種操作許可權是賦予角色(Role 或者 ClusterRole）的。通過建立 RoleBinding 或者 ClusterBinding 把 使用者(User),使用者組（Group）或服務賬號（Service Account）繫結在 Role 或 ClusterRole 上。這樣使用者，使用者組或者服務賬號就有了相對應的操作許可權。這裡有個需要注意的地方
ClusterRoleBinding 只能繫結 ClusterRole,而 RoleBinding 可以繫結 Role 或者 ClusterRole。
根據上圖：1.User1 通過 RoleBinding 把 Role 繫結，可以在 Namespace A 獲得 Role 中的許可權；2.User2 和 User3 通過 RoleBinding 把 ClusterRole 繫結，這兩個使用者即可以在 Namespace B 空間中獲得 ClusterRole 許可權；3.如果 User1 通過 ClusterRoleBinding 把 ClusterRole 繫結，這個使用者即可在所有的 Namespace 空間中獲得 ClusterRole 許可權；
Service account是為了方便Pod裡面的程式呼叫Kubernetes API或其他外部服務而設計的。它與User account不同，具體參看 https://www.kubernetes.org.cn/service-account 。
需要訪問 apiserver 需要經過 認證，授權，准入控制 三關。首先需要進行認證，認證通過後再進行授權檢查，因有些增刪等某些操作需要級聯到其他資源或者環境，這時候就需要准入控制來檢查級聯環境是否有授權許可權了。預設情況下，RBAC策略授予控制板元件、Node和控制器作用域的許可權，但是未授予“kube-system”名稱空間外服務帳戶的訪問許可權。這就允許管理員按照需要將特定角色授予服務帳戶。具體授權可以參看 Kubernetes-基於RBAC的授權： https://www.kubernetes.org.cn/4062.html 。
在k8s叢集的Pod 訪問API Server，就是需要使用Servive account 的RBAC的授權。下面的程式碼就是Kubernetes 客戶端KubeClient 的實現
從k8s 帶給pod的環境變數、token以及證書去訪問k8s API Server。
所以這裡就是要給Service Account 授權，授權可以參考Kubernetes-基於RBAC的授權： https://www.kubernetes.org.cn/4062.html