基于RBAC的role base鑒權是對kubernetes叢集内模型資源進行通路控制的标準做法，同時各主流雲廠商通常都有一套自身的通路控制引擎，就像EKS，GKE的IAM，AKS的ARM，阿裡雲的RAM服務；而對于普通使用者來說，如何了解二者的差別和邊界并做出正确的授權配置就成了一個令人頭疼的問題。
下面讓我們來了解一下各主流雲廠商k8s服務的認證鑒權流程。
AuthN & AuthZ in EKS
EKS沒有做到IAM與RBAC的統一授權，且僅支援CLI方式的叢集内RBAC授權。預設使用
aws-iam-authenticator完成請求的認證過程，其認證鑒權流程如下圖所示：
1 首先使用者用戶端的config憑證中需要通過exec字段配置用于認證的roleARN和叢集id
2 EKS apiserver配置了認證webhook，收到認證請求後發送至aws-iam-authenticator server，server端通過IAM sts:GetCallerIdentity接口傳回與指定的角色arn進行比對完成認證，同時通過configmap中指定的arn與使用者的映射關系找到k8s對應的使用者或組傳回
mapUsers:
- userARN: arn:aws:iam::012345678901:user/Jane
username: jane
- userARN: arn:aws:iam::012345678901:user/Joe
username: joe
3 如果認證失敗，apiserver傳回401至用戶端
4 認證成功後，apiserver根據傳回的使用者或組進行RBAC鑒權，注意這裡的RBAC鑒權所需的角色和綁定模型仍需要使用者通過cli手工完成配置。
AuthN & AuthZ in GKE
GKE在IAM中預置了幾種面向k8s叢集内的角色模型，使用者可以通過GCP IAM控制台的綁定操作擷取叢集内k8s模型資源的使用權限，同時支援使用者賬号郵箱作為IAM和K8S認證的統一身份，進而部分實作了IAM與RBAC的授權統一，下圖是GKE幾種預置k8s應用角色和RBAC預置clusterrole之間的權限映射關系，在
GKE文檔中有對幾種k8s相關預置角色的詳細說明。
這裡使用者需要注意的是GKE的Kubernetes Engine Admin角色相當于RBAC的cluster-admin，對叢集内所有模型具有全部權限，Developer對應RBAC edit，Viewer對應RBAC view角色；而Kubernetes Engine Cluster Admin反而沒有k8s叢集内資源的使用權限，隻有GKE cluster資源層面的管理權限，這種叢集管理平面和叢集内應用資料平面的權限隔離往往是令客戶感到困擾的地方。
另外，在實際的生産環境中，如果某使用者在IAM控制台内被授予了内置的Kubernetes Engine Developer角色，那麼他将擁有叢集所有namespace的寫權限，這也包括kube-system ns, 由于GKE還不支援ns粒度的一步授權，這在某些多租場景下是無法接受的。通常根據權限最小化原則，管理者隻會給普通使用者一個全局Viewer的權限，再通過手工配置RBAC角色綁定完成更細粒度的授權。在整個授權流程中IAM授權是基礎，而通過RBAC配置可以實作上層應用的精細化權限控制。
AuthN & AuthZ in AKS
AKS提供了Azure AD與k8s之間的認證身份內建能力，具體請
參見，使用者可面向Azure AD中的賬号郵箱或組id在k8s叢集中進行相應的RBAC角色綁定，為此AKS提供了CLI形式的綁定指令，當然這個過程仍然和Azure Resource Manager中的叢集管理平面RBAC授權是分裂的兩步操作。
值得一提的是Azure AD與AKS的認證內建利用k8s原生的oidc webhook認證模式很好的彌補k8s在使用者賬号管理能力上的不足，同時能夠更好地支援吊銷AD内使用者通路k8s的叢集憑證。
AuthN & AuthZ in ACK&AMK
阿裡雲容器服務的通路控制授權同樣需要劃分為管理平面授權和資料平面的授權，其中管理平面授權面向的是阿裡雲資源的權限控制，比如子賬号在控制台對叢集的可見性，叢集自動伸縮，下載下傳證書等權限都是由阿裡雲RAM服務來統一控制的，這也和阿裡雲其他雲服務資源的授權模式保持一緻。而對于叢集内k8s模型的權限控制，仍舊通過RBAC角色配置完成，整體授權流程如下圖所示，注意同GKE類似，RAM授權仍舊是整個授權流程的基礎，使用者需要確定首先完成RAM授權獲得叢集可見權限的基礎上，在上層完成叢集内應用資源的RBAC授權。
相較于其他雲廠商的授權流程，阿裡雲容器服務控制台提供了可視化的授權管理頁面，提供了如下能力：
- 提供了四種常用預置RBAC角色模闆的可視化增删配置，降低了權限管理者的rbac學習成本
- 支援叢集namespaces細粒度授權
- 同時支援多個叢集内使用者自定義clusterrole的自動綁定能力
- 支援RAM授權校驗能力，同時可以根據目前授權配置幫助使用者生成一個權限最小化的隻讀RAM政策模闆友善管理者進行管理平面的RAM授權
- 支援主賬号和具有叢集管理者角色子賬号的分級授權配置
- 支援所有叢集次元的批量授權
- 使用阿裡雲uid為RAM和RBAC授權的統一身份id，降低差異性；同時提供使用者對應config憑證的一鍵下載下傳能力
- 提供了基于RAM的k8s叢集 聯合認證支援工具
管理平面的雲平台資源授權和叢集内應用資源的RBAC授權本來就是一個專業化和精細化的複雜操作，通過如上特性，阿裡雲容器服務希望能夠幫助使用者更好的了解二者的差別并降低整個授權流程的複雜度。
在以上幾個主流雲廠商k8s叢集已經具備的認證授權能力之外，下面的幾個rbac相關的開源工具也是對整個授權流程的有效補充：
- kubectl auth can-i - kubectl原生指令，查詢指定使用者是否有相應的請求權限
- rakkess - 基于auth can-i，全局展示指定使用者對資源的所有操作權限
- kubectl-who-can - 用于查詢哪些使用者在該叢集中有指定操作的權限
- rbac-lookup - 查詢指定使用者的所有RBAC綁定權限
- RBAC-manager - 通過CRD的方式管理使用者對應的所有綁定，同時支援在滿足label selectors的ns中自動配置綁定