Kubernetes 鑒權 - RBAC
當一個請求在完成 api-server 認證後，可以認為它是一個合法的使用者，那麼如何控制該使用者在叢集中的哪些 namespace 中通路哪些資源，對這些資源又能進行哪些操作呢？
這就由通路控制的第二步 Kubernetes 鑒權來完成。api-server 本身支援多種鑒權方式，在本小結中，我們主要介紹在安全上推薦的鑒權方式 RBAC。
RBAC 鑒權三要素
- 第一要素是 Subjects，也就是主體。可以是開發人員、叢集管理者這樣的自然人，也可以是系統元件程序，或者是 Pod 中的邏輯程序；
- 第二個要素是 API Resource，也就是請求對應的通路目标。在 Kubernetes 叢集中也就是各類資源；
- 第三要素是 Verbs，對應為請求對象資源可以進行哪些操作，包括增删改查、list、get、watch 等。
這裡舉個例子，假設有個通過合法認證的使用者 Bob，他請求 list 某個 namespace下的 Pods，改請求的鑒權語義記為：Can Bob list pods ？其中 Bob 即為請求中的 Subject，list 為對應的請求動作 Action，而 pods 為對應的請求資源 Resource。
RBAC 權限粒度
上面介紹了 RBAC 角色模型的三要素，在整個 RBAC 政策定義下，還需要将這個角色綁定到一個具體的控制域内。這就是 Kubernetes 大家熟悉的命名空間。通過 namespace 可以将 Kubernetes api 資源限定在不同的作用域内。進而幫助我們在一個多租戶叢集中，對使用者進行邏輯上的隔離。
上面的事例可以改為 User A can create pods in namespace B。這裡需要注意的是，如果不進行任何的權限綁定，RBAC 會拒絕所有通路。
通常 RBAC 會進行對 api-server 的細粒度通路控制，但是這個細粒度是個相對的概念，RBAC 是面向模型級别的綁定。它不能綁定到 namespace 中的一個具體的 object 執行個體，更不能綁定到指定資源的任意一個 field。
RBAC 對通路權限的控制粒度上，它可以細化到 Kubernetes api 的 subresources 級别。比如針對一個通路者，我們可以控制其在指定 namespace 下對 nodes/status 模型的通路。
RBAC - Role
接着介紹 RBAC 具體的綁定權限和對象。
首先是角色 Role，它定義了使用者在指定的 Kubernetes 命名空間資源上可以進行哪些操作。比如可以定一個 namespace 中 pod 的隻讀權限，同時還可以定義一個 namespace 管理者權限，它具有對這個命名空間下所有對象資源的所有操作權限。
如上圖所示，是一個 Role 的定義模闆編排檔案，其中 resource 字段定義了這個角色可以通路哪些資源，verbs 字段定義了這個角色有哪些操作的權限。在 apiGroups 中，需要指定目标資源的 apiGroups 名稱，這裡可以通過官方 API 文檔查詢，如果指定的 Group 是 core，那麼在角色模闆中的 apiGroups 可置為空。
RBAC - RoleBinding
當我們完成了一個 namespace 下的角色定義之後，還需要建立其與使用這個角色的主體之間在 namespace 下的綁定關系，這裡需要一個 RoleBinding 模型。使用 RoleBinding 可以将 Role 對應的權限模型綁定到對應的 Subject 上。