所有的 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