所有的 kubernetes 集群中賬戶分為兩類，Kubernetes 管理的 serviceaccount(服務賬戶) 和 useraccount（用戶賬戶）?；诮巧脑L問控制（“RBAC”）使用“rbac.authorization.k8s.io”API 組來實現(xiàn)授權(quán)控制，允許管理員通過Kubernetes API動態(tài)配置策略。

API Server 內(nèi)部通過用戶認證后，然后進入授權(quán)流程。對合法用戶進行授權(quán)并且隨后在用戶訪問時進行鑒權(quán)，是權(quán)限管理的重要環(huán)節(jié)。
在 kubernetes 集群中，各種操作權(quán)限是賦予角色(Role 或者 ClusterRole）的。通過創(chuàng)建 RoleBinding 或者 ClusterBinding 把 用戶(User),用戶組（Group）或服務賬號（Service Account）綁定在 Role 或 ClusterRole 上。這樣用戶，用戶組或者服務賬號就有了相對應的操作權(quán)限。
這里有個需要注意的地方
ClusterRoleBinding 只能綁定 ClusterRole,而 RoleBinding 可以綁定 Role 或者 ClusterRole。
根據(jù)上圖：
1.User1 通過 RoleBinding 把 Role 綁定，可以在 Namespace A 獲得 Role 中的權(quán)限；
2.User2 和 User3 通過 RoleBinding 把 ClusterRole 綁定，這兩個用戶即可以在 Namespace B 空間中獲得 ClusterRole 權(quán)限；
3.如果 User1 通過 ClusterRoleBinding 把 ClusterRole 綁定，這個用戶即可在所有的 Namespace 空間中獲得 ClusterRole 權(quán)限；

Service account是為了方便Pod里面的進程調(diào)用Kubernetes API或其他外部服務而設計的。它與User account不同，具體參看?https://www.kubernetes.org.cn/service-account?。

需要訪問 apiserver 需要經(jīng)過 認證，授權(quán)，準入控制 三關(guān)。首先需要進行認證，認證通過后再進行授權(quán)檢查，因有些增刪等某些操作需要級聯(lián)到其他資源或者環(huán)境，這時候就需要準入控制來檢查級聯(lián)環(huán)境是否有授權(quán)權(quán)限了。默認情況下，RBAC策略授予控制板組件、Node和控制器作用域的權(quán)限，但是未授予“kube-system”命名空間外服務帳戶的訪問權(quán)限。這就允許管理員按照需要將特定角色授予服務帳戶。具體授權(quán)可以參看 Kubernetes-基于RBAC的授權(quán)：?https://www.kubernetes.org.cn/4062.html?。

在k8s集群的Pod 訪問API Server，就是需要使用Servive account 的RBAC的授權(quán)。下面的代碼就是Kubernetes 客戶端KubeClient?的實現(xiàn)

從k8s 帶給pod的環(huán)境變量、token以及證書去訪問k8s API Server。

所以這里就是要給Service Account 授權(quán)，授權(quán)可以參考Kubernetes-基于RBAC的授權(quán)：?https://www.kubernetes.org.cn/4062.html?

原文地址：https://www.cnblogs.com/shanyou/p/10856916.html

.NET社區(qū)新聞，深度好文，歡迎訪問公眾號文章匯總?http://www.csharpkit.com?

總結(jié)

以上是生活随笔為你收集整理的在kubernetes 集群内访问k8s API服务的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。