本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

Kubernetes 中的 RBAC 支援

作者：Jacob Simpson (Google), Greg Castle (Google), CJ Cullen (Google) |

編者注：本文是關於 Kubernetes 1.6 新功能的一系列深度文章的一部分

Kubernetes 1.6 版本的一大亮點是 RBAC 授權器功能已進入 *beta* 階段。RBAC（基於角色的訪問控制）是一種授權機制，用於管理 Kubernetes 資源許可權。RBAC 允許配置靈活的授權策略，這些策略可以在不重啟叢集的情況下進行更新。

本文的重點是突出一些有趣的新功能和最佳實踐。

RBAC 與 ABAC

目前，Kubernetes 提供了幾種授權機制。授權器是決定誰被允許使用 Kubernetes API 對叢集進行哪些更改的機制。這會影響 kubectl、系統元件，以及在叢集中執行並操作叢集狀態的某些應用程式，例如帶有 Kubernetes 外掛的 Jenkins，或在叢集中執行並使用 Kubernetes API 安裝應用程式的 Helm。在可用的授權機制中，ABAC 和 RBAC 是 Kubernetes 叢集本地的、允許可配置許可權策略的機制。

ABAC（基於屬性的訪問控制）是一個強大的概念。然而，在 Kubernetes 中的實現中，ABAC 難以管理和理解。它需要對叢集主 VM 進行 ssh 和根檔案系統訪問才能進行授權策略更改。許可權更改生效需要重啟叢集 API 伺服器。

RBAC 許可權策略直接使用 kubectl 或 Kubernetes API 進行配置。使用者可以使用 RBAC 本身被授權進行授權策略更改，從而無需授予叢集主節點 SSH 訪問許可權即可委託資源管理。RBAC 策略易於對映到 Kubernetes API 中使用的資源和操作。

基於 Kubernetes 社群的開發重點，今後應優先使用 RBAC 而非 ABAC。

基本概念

理解 RBAC 有幾個基本概念。其核心是，RBAC 是一種授予使用者對 Kubernetes API 資源精細訪問許可權的方式。

使用者和資源之間的連線在 RBAC 中使用兩個物件定義。

角色 (Roles)
角色是許可權的集合。例如，一個角色可以定義為包含對 Pod 的讀取許可權和對 Pod 的列表許可權。ClusterRole 就像一個角色，但可以在叢集中的任何地方使用。

角色繫結 (Role Bindings)
RoleBinding 將一個角色對映到一個或一組使用者，授予這些使用者該角色的許可權，以訪問該名稱空間中的資源。ClusterRoleBinding 允許使用者被授予一個 ClusterRole，以在整個叢集中進行授權。

此外，還需要考慮叢集角色和叢集角色繫結。叢集角色和叢集角色繫結功能類似於角色和角色繫結，只是它們的範圍更廣。具體差異以及叢集角色和叢集角色繫結如何與角色和角色繫結互動，詳見 Kubernetes 文件。

Kubernetes 中的 RBAC

RBAC 現已深度整合到 Kubernetes 中，並被系統元件用於授予其執行所需的許可權。系統角色通常以 system: 為字首，以便於識別。

➜  kubectl get clusterroles --namespace=kube-system

NAME                    KIND

admin ClusterRole.v1beta1.rbac.authorization.k8s.io

cluster-admin ClusterRole.v1beta1.rbac.authorization.k8s.io

edit ClusterRole.v1beta1.rbac.authorization.k8s.io

kubelet-api-admin ClusterRole.v1beta1.rbac.authorization.k8s.io

system:auth-delegator ClusterRole.v1beta1.rbac.authorization.k8s.io

system:basic-user ClusterRole.v1beta1.rbac.authorization.k8s.io

system:controller:attachdetach-controller ClusterRole.v1beta1.rbac.authorization.k8s.io

system:controller:certificate-controller ClusterRole.v1beta1.rbac.authorization.k8s.io

...

RBAC 系統角色已擴充套件，以涵蓋僅使用 RBAC 執行 Kubernetes 叢集所需的許可權。

在許可權從 ABAC 到 RBAC 的轉換過程中，一些在許多 ABAC 授權叢集部署中預設啟用的許可權被認為是過寬的，並在 RBAC 中縮小了範圍。最有可能影響叢集上工作負載的領域是服務賬戶可用的許可權。在寬鬆的 ABAC 配置下，使用 Pod 掛載令牌進行 API 伺服器認證的 Pod 請求具有廣泛的授權。舉一個具體的例子，當 ABAC 啟用時，此序列末尾的 curl 命令將返回 JSON 格式的結果；當僅啟用 RBAC 時，則返回錯誤。

➜  kubectl run nginx --image=nginx:latest

➜  kubectl exec -it $(kubectl get pods -o jsonpath='{.items[0].metadata.name}') bash

➜  apt-get update && apt-get install -y curl

➜  curl -ik \

 -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \

 https://kubernetes/api/v1/namespaces/default/pods

您在 Kubernetes 叢集中執行的任何與 Kubernetes API 互動的應用程式，在從 ABAC 遷移到 RBAC 時都可能受到許可權更改的影響。

為了平穩過渡從 ABAC 到 RBAC，您可以使用 ABAC 和 RBAC 授權器同時啟用建立 Kubernetes 1.6 叢集。當 ABAC 和 RBAC 都啟用時，如果任一授權策略授予訪問許可權，則授予對資源的授權。但是，在此配置下，將使用最寬鬆的授權器，並且無法使用 RBAC 完全控制權限。

目前，RBAC 已經足夠完善，ABAC 支援應被視為今後棄用。它在可預見的未來仍將保留在 Kubernetes 中，但開發重點已放在 RBAC 上。

Google Cloud Next 大會上的兩次不同演講都提到了 Kubernetes 1.6 中與 RBAC 相關的變化，您可以點選這裡和這裡跳到相關部分。有關在 Kubernetes 1.6 中使用 RBAC 的更詳細資訊，請閱讀完整的RBAC 文件。

參與其中

如果您想貢獻或只是幫助提供反饋並推動路線圖，請加入我們的社群。如果您特別對安全和 RBAC 相關對話感興趣，請透過以下渠道之一參與：

感謝您的支援和貢獻。請點選這裡閱讀更多關於 Kubernetes 1.6 新功能的深度文章。