k8s的認證受權

1、ServiceAccount

Service account是爲了方便Pod裏面的進程調用Kubernetes API或其餘外部服務而設計的。它與User account不一樣

 

User account是爲人設計的，而service account則是爲Pod中的進程調用Kubernetes API而設計；

User account是跨namespace的，而service account則是僅侷限它所在的namespace；

每一個namespace都會自動建立一個default service account

Token controller檢測service account的建立，併爲它們建立secret

開啓ServiceAccount Admission Controller後

每一個Pod在建立後都會自動設置spec.serviceAccount爲default（除非指定了其餘ServiceAccout）

驗證Pod引用的service account已經存在，不然拒絕建立

若是Pod沒有指定ImagePullSecrets，則把service account的ImagePullSecrets加到Pod中

每一個container啓動後都會掛載該service account的token和ca.crt到/var/run/secrets/kubernetes.io/serviceaccount/

 當建立 pod 的時候，若是沒有指定一個 service account，系統會自動在與該pod 相同的 namespace 下爲其指派一個default service account。而pod和apiserver之間進行通訊的帳號，稱爲serviceAccountName。

 

2、RBAC----基於角色的訪問控制

 Kubernetes的受權是基於插件形式的，其經常使用的受權插件有如下幾種：

 

Node（節點認證）

ABAC(基於屬性的訪問控制)

RBAC（基於角色的訪問控制）

Webhook（基於http回調機制的訪問控制）

 讓一個用戶（Users）扮演一個角色（Role），角色擁有權限，從而讓用戶擁有這樣的權限，隨後在受權機制當中，只須要將權限授予某個角色，此時用戶將獲取對應角色的權限，從而實現角色的訪問控制。

 

基於角色的訪問控制（Role-Based Access Control, 即」RBAC」）使用」rbac.authorization.k8s.io」 API Group實現受權決策，容許管理員經過Kubernetes API動態配置策略。

 

在k8s的受權機制當中，採用RBAC的方式進行受權，其工做邏輯是　　把對對象的操做權限定義到一個角色當中，再將用戶綁定到該角色，從而使用戶獲得對應角色的權限。此種方式僅做用於名稱空間當中，這是什麼意思呢？當User1綁定到Role角色當中，User1就獲取了對該NamespaceA的操做權限，可是對NamespaceB是沒有權限進行操做的，如get，list等操做。

另外，k8s爲此還有一種集羣級別的受權機制，就是定義一個集羣角色（ClusterRole），對集羣內的全部資源都有可操做的權限，從而將User2，User3經過ClusterRoleBinding到ClusterRole，從而使User二、User3擁有集羣的操做權限。Role、RoleBinding、ClusterRole和ClusterRoleBinding的關係

 

可是這裏有2種綁定ClusterRoleBinding、RoleBinding。也能夠使用RoleBinding去綁定ClusterRole。

當使用這種方式進行綁定時，用戶僅能獲取當前名稱空間的全部權限。爲何這麼繞呢？？舉例有10個名稱空間，每一個名稱空間都須要一個管理員，而該管理員的權限都是一致的。那麼此時須要去定義這樣的管理員，使用RoleBinding就須要建立10個Role，這樣顯得更加繁重。爲此當使用RoleBinding去綁定一個ClusterRole時，該User僅僅擁有對當前名稱空間的集羣操做權限，換句話說，此時只須要建立一個ClusterRole就解決了以上的需求。

 

 這裏要注意的是：RoleBinding僅僅對當前名稱空間有對應的權限。

 

在RBAC API中，一個角色包含了一套表示一組權限的規則。 權限以純粹的累加形式累積（沒有」否認」的規則）。 角色能夠由命名空間（namespace）內的Role對象定義，而整個Kubernetes集羣範圍內有效的角色則經過ClusterRole對象實現。

 

 

 4、RBAC的三種受權訪問

RBAC不單單能夠對user進行訪問權限的控制，還能夠經過group和serviceaccount進行訪問權限控制。當咱們想對一組用戶進行權限分配時，便可將這一組用戶歸併到一個組內，從而經過對group進行訪問權限的分配，達到訪問權限控制的效果。

 

從前面serviceaccount咱們能夠了解到，Pod能夠經過 spec.serviceAccountName來定義其是以某個serviceaccount的身份進行運行，當咱們經過RBAC對serviceaccount進行訪問受權時，便可以實現Pod對其餘資源的訪問權限進行控制。也就是說，當咱們對serviceaccount進行rolebinding或clusterrolebinding，會使建立Pod擁有對應角色的權限和apiserver進行通訊。