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

Kubernetes 中的 RBAC 支援

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

編輯註：這篇文章是關於 Kubernetes 1.6 新功能的系列深入文章的一部分

Kubernetes 1.6 版本的一大亮點是 RBAC 授權器功能轉為測試版。RBAC（基於角色的存取控制）是一種授權機制，用於管理 Kubernetes 資源的權限。RBAC 允許配置彈性的授權策略，這些策略可以在不重新啟動叢集的情況下更新。

這篇文章的重點是強調一些有趣的新功能和最佳實務。

RBAC vs 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 中使用兩個物件定義。

角色
角色是權限的集合。例如，可以將角色定義為包括 Pod 的讀取權限和 Pod 的清單權限。ClusterRole 與角色類似，但可以在叢集中的任何位置使用。

角色綁定
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 的請求使用 Pod 掛載的令牌向 API 伺服器進行身份驗證，具有廣泛的授權。作為一個具體的例子，當啟用 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

當從 ABAC 轉換到 RBAC 時，您在 Kubernetes 叢集中運行的任何與 Kubernetes API 互動的應用程式都可能受到權限變更的影響。

為了平滑從 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 新功能的深入文章此處。