基於角色的訪問控制最佳實踐

Kubernetes RBAC 是一種關鍵的安全控制，旨在確保叢集使用者和工作負載只擁有執行其角色所需的資源訪問許可權。叢集管理員在設計叢集使用者的許可權時，必須瞭解可能發生特權升級的區域，以降低過度訪問導致安全事件的風險。

此處列出的良好實踐應結合一般的 RBAC 文件閱讀。

一般良好實踐

最小許可權原則

理想情況下，應為使用者和服務賬號分配最小的 RBAC 許可權。只應使用其操作明確所需的許可權。儘管每個叢集都會有所不同，但可以應用一些通用規則：

• 儘可能在名稱空間級別分配許可權。使用 RoleBinding 而不是 ClusterRoleBinding，以僅在特定名稱空間內賦予使用者許可權。
• 儘可能避擴音供萬用字元許可權，特別是對所有資源的萬用字元許可權。由於 Kubernetes 是一個可擴充套件系統，提供萬用字元訪問許可權不僅賦予了對叢集中當前存在的所有物件型別的權利，還賦予了對未來建立的所有物件型別的權利。
• 管理員不應使用 cluster-admin 賬號，除非特別需要。提供一個具有 模擬許可權的低許可權賬號，可以避免意外修改叢集資源。
• 避免將使用者新增到 system:masters 組。此組的任何成員都會繞過所有 RBAC 許可權檢查，並始終擁有不受限制的超級使用者訪問許可權，無法透過刪除 RoleBinding 或 ClusterRoleBinding 來撤銷。此外，如果叢集正在使用授權 Webhook，此組成員身份也會繞過該 Webhook（來自此組成員使用者的請求永遠不會發送到 Webhook）。

最小化特權令牌的分發

理想情況下，不應為 Pod 分配已授予強大許可權（例如，特權升級風險下所列的任何許可權）的服務賬號。在工作負載需要強大許可權的情況下，請考慮以下實踐：

• 限制執行強大 Pod 的節點數量。確保你執行的所有 DaemonSet 都是必要的，並以最小許可權執行，以限制容器逃逸的影響範圍。
• 避免將強大 Pod 與不受信任或公開的 Pod 一同執行。考慮使用 汙點和容忍度、節點親和性或 Pod 反親和性來確保 Pod 不與不受信任或信任度較低的 Pod 一同執行。特別注意信任度較低的 Pod 不符合 **Restricted** Pod 安全標準的情況。

強化

Kubernetes 預設提供訪問許可權，這在某些叢集中可能不需要。審查預設提供的 RBAC 許可權可以提供安全強化的機會。一般來說，不應對提供給 system: 賬號的許可權進行更改，但存在一些強化叢集許可權的選項：

• 審查 system:unauthenticated 組的繫結，並在可能的情況下將其刪除，因為這會賦予任何能在網路層面聯絡到 API 伺服器的人訪問許可權。
• 透過設定 automountServiceAccountToken: false 避免預設自動掛載服務賬號令牌。有關更多詳細資訊，請參閱 使用預設服務賬號令牌。為 Pod 設定此值將覆蓋服務賬號設定，需要服務賬號令牌的工作負載仍然可以掛載它們。

定期審查

定期審查 Kubernetes RBAC 設定以查詢冗餘條目和可能的特權升級至關重要。如果攻擊者能夠建立與已刪除使用者同名的使用者賬號，他們可以自動繼承已刪除使用者的所有許可權，特別是分配給該使用者的許可權。

Kubernetes RBAC - 特權升級風險

在 Kubernetes RBAC 中，如果授予某些許可權，使用者或服務賬號可以在叢集中升級其特權，或影響叢集外的系統。

本節旨在讓叢集操作員瞭解需要謹慎的領域，以確保他們不會無意中允許對叢集進行超出預期的訪問。

列出 Secret

通常很清楚，允許對 Secret 進行 get 訪問將允許使用者讀取其內容。同樣重要的是要注意，list 和 watch 訪問也有效地允許使用者洩露 Secret 內容。例如，當返回 List 響應時（例如，透過 kubectl get secrets -A -o yaml），響應包含所有 Secret 的內容。

工作負載建立

在名稱空間中建立工作負載（Pod 或管理 Pod 的工作負載資源）的許可權隱含地授予了對該名稱空間中許多其他資源的訪問許可權，例如可以在 Pod 中掛載的 Secret、ConfigMap 和 PersistentVolume。此外，由於 Pod 可以作為任何服務賬號執行，授予建立工作負載的許可權也隱含地授予了該名稱空間中任何服務賬號的 API 訪問級別。

能夠執行特權 Pod 的使用者可以利用該訪問許可權獲取節點訪問許可權，並可能進一步提升其特權。如果你不完全信任使用者或其他主體能夠建立足夠安全和隔離的 Pod，則應強制執行 **Baseline** 或 **Restricted** Pod 安全標準。你可以使用 Pod 安全准入或其他（第三方）機制來實施該強制措施。

由於這些原因，名稱空間應用於分離需要不同信任級別或租戶的資源。遵循最小許可權原則並分配最小許可權集仍然被認為是最佳實踐，但名稱空間內的邊界應被認為是薄弱的。

PersistentVolume 建立

如果允許某人或某個應用程式建立任意 PersistentVolume，則該訪問許可權包括建立 hostPath 卷，這意味著 Pod 將獲得對關聯節點上底層主機檔案系統（或多個檔案系統）的訪問許可權。授予此能力存在安全風險。

具有對主機檔案系統無限制訪問許可權的容器有許多方法可以升級許可權，包括從其他容器讀取資料，以及濫用系統服務（如 Kubelet）的憑據。

你只應允許以下人員建立 PersistentVolume 物件：

• 因工作需要此訪問許可權且你信任的使用者（叢集操作員）。
• 根據配置為自動配置的 PersistentVolumeClaim 建立 PersistentVolume 的 Kubernetes 控制平面元件。這通常由 Kubernetes 提供商或操作員在安裝 CSI 驅動程式時進行設定。

在需要持久儲存訪問許可權的情況下，受信任的管理員應建立 PersistentVolume，受限制的使用者應使用 PersistentVolumeClaim 訪問該儲存。

訪問節點的 proxy 子資源

有權訪問節點物件的代理子資源的使用者擁有 Kubelet API 的許可權，這允許在他們有許可權的節點上的每個 Pod 上執行命令。此訪問許可權繞過了審計日誌和准入控制，因此在授予此資源許可權之前應謹慎行事。

escalate 動詞

通常，RBAC 系統會阻止使用者建立擁有比使用者更多許可權的 ClusterRole。此規則的例外是 escalate 動詞。如 RBAC 文件所述，擁有此許可權的使用者可以有效地升級其特權。

bind 動詞

與 escalate 動詞類似，授予使用者此許可權允許繞過 Kubernetes 內建的特權升級保護，允許使用者建立繫結到其尚未擁有的許可權的 Role。

impersonate 動詞

此動詞允許使用者模擬並獲得叢集中其他使用者的許可權。在授予此許可權時應謹慎，以確保不會透過被模擬的賬號獲得過多的許可權。

CSR 和證書頒發

CSR API 允許具有 CSR create 許可權和 certificatesigningrequests/approval update 許可權的使用者，其中籤署者是 kubernetes.io/kube-apiserver-client，來建立新的客戶端證書，從而允許使用者向叢集進行身份驗證。這些客戶端證書可以具有任意名稱，包括與 Kubernetes 系統元件重複的名稱。這將有效地導致特權升級。

令牌請求

對 serviceaccounts/token 具有 create 許可權的使用者可以建立 TokenRequest 以頒發現有服務賬號的令牌。

控制准入 Webhook

控制 validatingwebhookconfigurations 或 mutatingwebhookconfigurations 的使用者可以控制 Webhook，這些 Webhook 可以讀取叢集中准入的任何物件，對於 mutating Webhook，還可以修改准入的物件。

名稱空間修改

能夠對名稱空間物件執行 **patch** 操作的使用者（透過名稱空間 RoleBinding 到具有該訪問許可權的 Role）可以修改該名稱空間上的標籤。在使用 Pod 安全准入的叢集中，這可能允許使用者將名稱空間配置為比管理員預期更寬鬆的策略。對於使用 NetworkPolicy 的叢集，使用者可能會設定標籤，間接允許訪問管理員不打算允許的服務。

Kubernetes RBAC - 拒絕服務風險

物件建立拒絕服務

有權在叢集中建立物件的使用者可能能夠建立足夠大的物件，從而根據物件的大小或數量造成拒絕服務狀況，如 Kubernetes 使用的 etcd 易受 OOM 攻擊中所述。這在多租戶叢集中可能特別相關，如果允許半受信任或不受信任的使用者對系統進行有限訪問。

解決此問題的一種選擇是使用 資源配額來限制可以建立的物件數量。

下一步

• 要了解有關 RBAC 的更多資訊，請參閱 RBAC 文件。