在kubernetes 集羣內訪問k8s API服務

全部的 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