AKS Azure RBAC 概念解析

這兩篇準備來談談Azure中關于AKS的RBAC，正好之前剛剛談完AKS和AzureAD的內建，AKS在這方面稍顯複雜一些，是以可以先把一些基礎的概念做下普及

正常來講，如果AKS叢集沒開啟和Azure AD內建的話，那麼如果想對叢集進行操作的話，有幾種途徑

有對AKS的管理權限，可以下載下傳kubeconfig，并且所處的角色有操作叢集資源的權限，這種情況一般拿到的就是cluster admin的權限

如果想劃分細粒度的權限，可以按照傳統的K8S RBAC方式建立使用者等，但是沒辦法賦權給AzureAD的identity

如果開啟了Azure AD內建的話，則可以結合K8S本身的RBAC，把權限授權給AzureAD的使用者群組等，這樣授權其實對使用者來說使用要友善很多，是以還是建議把Azure AD內建打開

而今天要講的這個Azure RBAC其實是獨立出來的另外一個概念，Azure對于每個服務其實都有一些特定的role，比如vm會有virtual machine contributor這種role，AKS也不例外，這方面的内置角色主要有兩種

名字帶RBAC的

Azure Kubernetes 服務 RBAC 檢視者

Azure Kubernetes 服務 RBAC 寫入者

Azure Kubernetes 服務 RBAC 管理者

Azure Kubernetes 服務 RBAC 群集管理者

名字不帶RBAC的

Azure Kubernetes 服務參與者角色

Azure Kubernetes 服務群集使用者角色

Azure Kubernetes 服務群集管理者角色

這兩種類型的角色側重點有所不同

帶RBAC的角色對AKS叢集本身沒有任何管理權限，連叢集資訊都看不到，純粹是管理AKS叢集内部resource的，比如pod, namespace等等

不帶RBAC的角色其實名字聽起來很混淆，看起來好像都能管理叢集，但是實際則不然，隻有Azure Kubernetes 服務參與者角色對AKS叢集有管理權限，可以執行更新，删除等操作，那剩下兩個叢集使用者和叢集管理者是做啥的呢。。說起來感覺會有點怪，這倆角色其實唯一的權限就是可以下載下傳kubeconfig。。隻不過叢集使用者角色下載下傳的是普通使用者的config，而叢集管理者可以通過--admin的參數，繞過AzureAD的身份驗證，直接拿到admin權限

經過簡單解釋，相信對于這些内置角色，應該能有一定認知了，我們要特别講的Azure RBAC其實特指的是名字帶RBAC的這幾個角色，首先可以來看下這些角色的定義

https://docs.microsoft.com/zh-cn/azure/aks/concepts-identity?WT.mc_id=AZ-MVP-5001235

角色

描述

允許進行隻讀通路并檢視命名空間中的大多數對象。 不允許檢視角色或角色綁定。 此角色不允許檢視 Secrets，因為通過讀取機密内容可以通路命名空間中的 ServiceAccount 憑據，這樣就會允許以命名空間中任何 ServiceAccount 的身份進行 API 通路（一種特權提升形式）

允許對命名空間中的大多數對象進行讀/寫通路。 此角色不允許檢視或修改角色或角色綁定。 但是，此角色允許以命名空間中任何 ServiceAccount 的身份通路 Secrets 和運作 Pod，是以可用于擷取命名空間中任何 ServiceAccount 的 API 通路級别。

允許要在命名空間内授予的管理者通路權限。 允許對命名空間（或群集範圍）中的大多數資源進行讀/寫通路，包括在命名空間内建立角色和角色綁定。 此角色不允許對資源配額或命名空間本身進行寫入通路。

允許超級使用者通路權限（對任何資源執行任何操作）。 它提供對群集中每個資源和所有命名空間的完全控制。

聽起來很實用的樣子，有了這幾個角色，其實我們就不需要那麼麻煩要自己通過role binding來配置設定權限了，但是實際上想把這個功能用起來真的沒那麼容易，需要不少彎彎道道

需要開啟Azure AD內建

需要開啟K8S RBAC

這個feature是個preview的feature，還需要先進行注冊才能使用，否則是沒辦法用起來的，我剛開始也是被坑了一道才發現了這個問題

而且21v版本的RBAC角色定義還有點問題，之前reader角色允許的操作裡居然有不少write，提了case之後現在已經改過來了

而把這幾個前提條件都搞定之後，才能讓你真的用上這個功能！

後邊就來看下具體怎麼操作