基於角色的存取控制最佳實務

Kubernetes RBAC 是一項重要的安全控制，可確保叢集使用者和工作負載僅具有執行其角色所需的資源存取權。務必確保在為叢集使用者設計權限時，叢集管理員了解可能發生權限提升的區域，以降低過度存取導致安全事件的風險。

此處列出的良好實務應與一般 RBAC 文件 一起閱讀。

一般良好實務

最小權限

理想情況下，應為使用者和服務帳戶指派最小權限的 RBAC 權限。 僅應使用其運作明確需要的權限。 雖然每個叢集都會有所不同，但以下是一些可以應用的通用規則：

• 盡可能在命名空間層級指派權限。 使用 RoleBindings 而非 ClusterRoleBindings，僅在特定命名空間內授予使用者權限。
• 盡可能避免提供萬用字元權限，尤其針對所有資源。 由於 Kubernetes 是一個可擴展的系統，提供萬用字元存取權不僅授予目前叢集中存在的所有物件類型權限，也授予未來建立的所有物件類型權限。
• 管理員除非在明確需要的情況下，否則不應使用 cluster-admin 帳戶。 提供具有 模擬權限 的低權限帳戶可以避免意外修改叢集資源。
• 避免將使用者加入 system:masters 群組。 任何屬於此群組的使用者都會繞過所有 RBAC 權限檢查，並且始終擁有不受限制的超級使用者存取權，這無法透過移除 RoleBindings 或 ClusterRoleBindings 來撤銷。 此外，如果叢集正在使用授權 webhook，則此群組的成員資格也會繞過該 webhook（來自屬於該群組的使用者的請求永遠不會傳送到 webhook）。

最小化特權令牌的分發。

理想情況下，不應將 Pod 指派給已被授予強大權限的服務帳戶（例如，特權提升風險下列出的任何權限）。 在工作負載需要強大權限的情況下，請考慮以下實務做法：

• 限制執行高權限 Pod 的節點數量。 確保您執行的任何 DaemonSets 都是必要的，並以最小權限執行，以限制容器逃逸的影響範圍。
• 避免在高權限 Pod 旁執行不受信任或公開暴露的 Pod。 考慮使用 Taints 和 Toleration、NodeAffinity 或 PodAntiAffinity，以確保 Pod 不會與不受信任或信任度較低的 Pod 一起執行。 特別注意較不可靠的 Pod 未符合 Restricted Pod 安全標準的情況。

強化安全性

Kubernetes 預設提供在每個叢集中可能不需要的存取權。 檢閱預設提供的 RBAC 權限可以提供強化安全性的機會。 一般來說，不應變更提供給 system: 帳戶的權限，但存在一些強化叢集權限的選項：

• 檢閱 system:unauthenticated 群組的綁定，並在可能的情況下移除它們，因為這會讓任何可以在網路層級聯絡 API 伺服器的人員獲得存取權。
• 透過設定 automountServiceAccountToken: false 來避免預設自動掛載服務帳戶令牌。 如需更多詳細資訊，請參閱使用預設服務帳戶令牌。 為 Pod 設定此值將覆寫服務帳戶設定，但需要服務帳戶令牌的工作負載仍然可以掛載它們。

定期檢閱

定期檢閱 Kubernetes RBAC 設定中是否有冗餘條目和可能的權限提升至關重要。 如果攻擊者能夠建立與已刪除使用者同名的使用者帳戶，他們可以自動繼承已刪除使用者的所有權限，尤其是指派給該使用者的權限。

Kubernetes RBAC - 權限提升風險

在 Kubernetes RBAC 中，有許多權限，如果授予這些權限，使用者或服務帳戶可能會提升其在叢集中的權限或影響叢集外部的系統。

本節旨在提供叢集操作員應注意的領域的可見性，以確保他們不會在無意中允許對叢集進行超出預期的存取。

列出密鑰

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

工作負載建立

在命名空間中建立工作負載（Pod 或管理 Pod 的 工作負載資源）的權限隱含地授予對該命名空間中許多其他資源的存取權，例如可以掛載在 Pod 中的 Secrets、ConfigMaps 和 PersistentVolumes。 此外，由於 Pod 可以以任何 ServiceAccount 身分執行，因此授予建立工作負載的權限也隱含地授予該命名空間中任何服務帳戶的 API 存取層級。

可以執行特權 Pod 的使用者可以使用該存取權來獲得節點存取權，並可能進一步提升其權限。 如果您不完全信任使用者或其他主體具有建立適當安全且隔離的 Pod 的能力，則應強制執行 Baseline 或 Restricted Pod 安全標準。 您可以使用 Pod 安全許可 或其他（第三方）機制來實作該強制執行。

由於這些原因，命名空間應用於分隔需要不同信任層級或租戶的資源。 遵循 最小權限 原則並指派最小權限集仍然被認為是最佳實務，但命名空間內的邊界應被視為較弱的。

持久卷建立

如果允許某人（或某些應用程式）建立任意 PersistentVolumes，則該存取權包括建立 hostPath 卷，這表示 Pod 將獲得對相關節點上底層主機檔案系統的存取權。 授予該能力是一種安全風險。

具有對主機檔案系統無限制存取權的容器可以透過多種方式提升權限，包括從其他容器讀取資料，以及濫用系統服務（例如 Kubelet）的憑證。

您應僅允許對以下對象建立 PersistentVolume 物件的存取權：

• 需要此存取權才能工作且您信任的使用者（叢集操作員）。
• Kubernetes 控制平面元件，它根據為自動佈建設定的 PersistentVolumeClaims 建立 PersistentVolumes。 這通常由 Kubernetes 提供商或操作員在安裝 CSI 驅動程式時設定。

在需要持久儲存存取權的情況下，受信任的管理員應建立 PersistentVolumes，而受限使用者應使用 PersistentVolumeClaims 來存取該儲存。

存取節點的 proxy 子資源

具有節點物件 proxy 子資源存取權的使用者有權存取 Kubelet API，這允許在他們有權存取的節點上的每個 Pod 上執行命令。 此存取權繞過稽核日誌記錄和許可控制，因此在授予此資源的權限之前應謹慎。

Escalate 動詞

一般來說，RBAC 系統會阻止使用者建立權限超過使用者擁有的 clusterroles。 例外情況是 escalate 動詞。 如 RBAC 文件 中所述，具有此權限的使用者可以有效地提升其權限。

Bind 動詞

與 escalate 動詞類似，授予使用者此權限允許繞過 Kubernetes 內建的權限提升保護機制，允許使用者建立與他們尚未擁有的權限的角色的綁定。

Impersonate 動詞

此動詞允許使用者模擬並獲得叢集中其他使用者的權限。 授予此權限時應謹慎，以確保不會透過其中一個模擬帳戶獲得過多的權限。

CSR 和憑證頒發

CSR API 允許具有 CSR 的 create 權限和 certificatesigningrequests/approval 的 update 權限的使用者，其中簽署者為 kubernetes.io/kube-apiserver-client，以建立新的用戶端憑證，允許使用者向叢集進行身份驗證。 這些用戶端憑證可以具有任意名稱，包括 Kubernetes 系統元件的重複項。 這將有效地允許權限提升。

令牌請求

具有 serviceaccounts/token 的 create 權限的使用者可以建立 TokenRequests 以為現有的服務帳戶頒發令牌。

控制許可 webhook

控制 validatingwebhookconfigurations 或 mutatingwebhookconfigurations 的使用者可以控制 webhook，這些 webhook 可以讀取任何被許可加入叢集的物件，並且在 mutating webhook 的情況下，還可以變更被許可加入的物件。

命名空間修改

可以對命名空間物件執行 patch 操作的使用者（透過命名空間 RoleBinding 到具有該存取權的角色）可以修改該命名空間上的標籤。 在使用 Pod 安全許可的叢集中，這可能允許使用者為命名空間配置比管理員預期更寬鬆的策略。 對於使用 NetworkPolicy 的叢集，使用者可能會設定間接允許存取管理員不希望允許的服務的標籤。

Kubernetes RBAC - 阻斷服務風險

物件建立阻斷服務

具有在叢集中建立物件權限的使用者可能能夠建立足夠大的物件，以造成阻斷服務狀況，無論是基於物件的大小還是數量，如 Kubernetes 使用的 etcd 容易受到 OOM 攻擊 中所述。 如果允許半信任或不受信任的使用者有限地存取系統，這在多租戶叢集中可能尤其相關。

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

下一步

• 若要進一步瞭解 RBAC，請參閱 RBAC 文件。