翻譯|K8s權限提升: 集群中過多權限引發的安全問題

原文白皮書
https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms

起初是看到POH Team的這篇谷歌云漏洞賞金計劃2022Top7案例學習參考；其中5th Prize: Kubernetes Privilege Escalation: Excessive Permissions in Popular Platforms；這是一篇來自paloalto的白皮書，并沒有直接描述漏洞或者安全問題，但是其揭示了諸多提供Kubernetes服務的公有云廠商在pods失陷后與特權下的"DaemonSets"容器產生的權限提升的火花，并給出了kubernetes權限配置安全合理性的檢測工具；Google認為這對于Kubernetes生態有所裨益，因此給出了$17311的獎勵

前言

近年來越來越多的用戶部署和使用，k8s使用量猛增，不安全的默認配置是新興復雜平臺典型的成長陣痛，k8s也是，但現在大多數k8s平臺已經根除不安全的默認配置，之前廣泛存在的未授權錯誤配置（例如未授權的kubelet訪問）已經越來越少見，習慣通過簡單的攻擊來破壞集群的攻擊者們可能對此提升不太滿意，但務實的攻擊者們開始著手目標針對更微妙的問題，

Unit 42團隊最近在野目睹了這種趨勢，因為它們捕獲了Siloscape樣本，一個迄今最復雜的k8s惡意軟體樣本，它將多個漏洞連接在一起，以危害Pod，逃逸并接管Node，最侄訓取整個集群的控制權，這個樣本演示了一種以前從未在野見過的方法：在破壞一個node節點后，它會檢查節點是否有過多權限，如果沒有就不會繼續攻擊，

隨著相對簡單的k8s攻擊失去關聯性，攻擊者開始瞄準過多權限和RBAC錯誤配置，

Kubernetes 基于角色的訪問控制 (RBAC) 是 Kubernetes 中的主要授權?案，管理用戶、組、pod 和節點對 Kubernetes 資源的權限

K8s RBAC配置具有強制最小權限訪問以避免攻擊者的能力，但錯誤配置很容易被忽視，看似受限的權限通常有強大的功能，如這個基本的問題“哪些Pods可以提升權限？”很難回答，在本報告中旨在解決這個問題，我們引入一個框架，該框架根據強大的權限所引發的攻擊對它們進行分類；有數十個最強大的k8s權限映射；并發布rbac-police，這是一個開源工具可以識別K8s集群中高權限和提權路徑，

為了解高權限的普遍性和影響，我們分析了流行的 Kubernetes 平臺——托管服務、發行、CNI——尋找以過多權限運行的基礎設施組件，在檢查的62.5%的k8s平臺中，強大的DaemonSet在集群中每個節點上發布了高權限憑證，因此在50%的平臺中，單個容器逃逸就足以危及整個集群，

DaemonSet 通常用于將基礎設施 Pod 部署到所有作業節點上，

我們與受影響的平臺合作解決這些問題并剝奪過多的權限，原來運行強大DaemonSet的62.5%只剩下25%，同樣，容器逃逸肯定會導致集群接管的平臺百分比從 50% 下降到僅 25%，而且很快還會有更多平臺出現這種情況，雖然這朝著正確的方向發展，但 RBAC 錯誤配置和過多的權限在不久的將來可能仍然是 Kubernetes 的重大安全風險，

請繼續閱讀，以更好地了解RBAC風險以及如何通過開源?具和最佳實踐配置來解決這些風險，學習將 RBAC 從盲點轉變為額外的防御層，

執行摘要

近年來，Kubernetes 平臺在安全性方面取得了重大進展，消除了嚴重的錯誤配置并建立了安全基線，由于容易受到直接攻擊的集群越來越少，威脅行為者開始適應并尋找濫用更微妙問題的技術，最近的惡意軟體樣本表明Kubernetes 威脅參與者開始針對過多的權限，

Kubernetes基于角色的訪問控制(RBAC) 是?種授權方案，用于管理用戶、組、服務賬戶和 pod 對 Kubernetes 資源的權限，如果使用得當，RBAC 可以強制執行最低權限的訪問并使攻擊者失望，如果配置錯誤，過多的權限會使集群面臨權限升級攻擊，并增加受損憑證和容器逃逸的影響范圍，

RBAC錯誤配置很容易被忽略

看似受限的權限可能非常強大，在某些情況下，與集群管理相當，因此，開源附加組件和基礎設施組件會無意中請求強大的權限，而用戶在沒有意識到對其集群安全性的全面影響的情況下授予了這些權限，

Prisma? Cloud 研究人員確定了數十種強大的 Kubernetes 權限（已知的和新穎的），并根據它們引發的攻擊將它們分類為五種主要的 Kubernetes 攻擊型別，

高權限廣泛存在

為了了解強大權限的普遍性，Prisma Cloud 研究人員分析了流行的 Kubernetes 平臺（托管服務、發行版和容器網路介面 (CNI)），以識別強大的 DaemonSet，這些 DaemonSet 可以在集群中的每個節點上分發強大的憑據，

在檢查的 Kubernetes 發行版和托管服務中，75% 默認運行強大的 DaemonSet，其余 25% 的人在啟用推薦功能的情況下也這樣做了，檢查主流容器網路介面(CNI)，50% 默認安裝強大的 DaemonSet，

過多權限導致影響大的攻擊

當松散地授予強大的權限時，它們更有可能落入壞人之手，在Kubernetes中，這可能以多種方式發生，但通過強大的DaemonSet和容器逃逸最容易看到，

當強大的 DaemonSets 在每個節點上分配強大的令牌時，容器逃逸的危害范圍會急劇增加，根據已識別的DaemonSet，在所審查的50%的Kubernetes平臺中，單個容器逃逸足以危及整個集群，

在 12.5% 的平臺中，單個容器逃逸可能足以接管一些集群，對于另外 12.5% 的人來說，如果啟用了推薦的功能，容器逃逸足以危及整個集群，

圖 2：所分析的 Kubernetes 平臺中容器逃逸的影響

RBAC錯誤配置是可解決的

Prisma Cloud 研究人員與供應商和開源專案合作，剝離過多的權限并減少強大憑據的分發，原來運行強大DaemonSet的62.5%只剩下25%，同樣，容器逃逸保證導致集群接管的平臺數量從50%下降到僅25%，這表明RBAC錯誤配置是可以解決的，并且強?的權限通常可以被洗掉，它還強調了受審查的供應商和開源專案對其平臺安全的承諾，

為了幫助 Kubernetes 用戶評估和改善其集群的RBAC狀況，本報告與rbac-police一起發布，一個新的開源工具，可以識別Kubernetes集群中強大的權限和特權升級路徑，新的RBAC檢查也貢獻給了Checkov，領先的開源基礎設施即代碼(IaC)掃描器，
最后，“建議”部分探討了?些最佳實踐，這些最佳實踐可以減少強大憑據的分發并限制受損憑據的傳播半徑，以及可以實時檢測和防止權限升級攻擊的準入策略，

基于角色的訪問控制101

Kubernetes RBAC 是?種授權方案，用于管理對 Kubernetes 資源的訪問，權限分為 Roles 或 ClusterRoles，并且可以通過 RoleBindings 或 ClusterRoleBindings 授予用戶、組和服務賬號，通過 RoleBindings 授予的權限僅限于命名空間，而通過 ClusterRoleBindings 授予的權限實際上在集群范圍內有效，

例如，下面的 ClusterRoleBinding 將“pod-reader”ClusterRole 授予“read er-sa”服務賬號SA，

“reader-sa”服務現在賬號已被授權執行“pod-reader”ClusterRole 中list的操作，

如上所示，K8s權限可以通過規則來表達，每個規則允許對一個或多個API組中一個或多個資源，執行一個或多個動作，上述規則允許在核心API組中list列舉和get獲取pod，常見的動作動詞包括：

? get: retrieve a resource by name 根據名稱檢索資源
? list: retrieve all resources 檢索全部資源
? create: create a resource 創建資源
? update: replace an existing resource 替換現有資源
? patch: modify an existing resource 修改現有資源
? delete: delete a resource 洗掉資源

如圖3所示，可以通過將Role和ClusterRole(也就是權限)系結到Pod的服務賬號來授予Pod權限，分配了"reader-sa"服務賬號的Pod能夠檢索集群范圍內的pod，

對高k8s權限進行分類

攻擊者可能會濫用某些 Kubernetes 權限來升級權限、橫向移動或獲得對集群更廣泛的控制，從現在開始，這些將被稱為“強大的權限”，

一些強大的權限幾乎相當于集群管理員，而其他權限只能在特定場景下濫用以進行有限的攻擊，為了在討論強大的權限時建立一個通用框架，我們根據它們所引發的攻擊將它們分為五種攻擊型別，

當涉及到強大的權限時，范圍是關鍵，當在整個集群上授予權限時，權限可以與管理員等效，但當范圍僅限于命名空間或特定資源名稱時，權限是無害的，為了包含所有可能的強大權限，上表假設在集群范圍內授予權限，

某些強大的權限會引發多種攻擊，因此會映射到多個攻擊類別，另一方面，一些更復雜的攻擊需要結合列出的權限才能執行，不足以自行發起攻擊的權限被標記為黃色，

為了避免不成比例的膨脹，表 1 匯總了類似的動作和資源，更新update和補丁patch動作聚合為虛擬的“modify”修改動詞，而修改modify和創建create則組合稱為"control"控制， DaemonSets、Deployments、CronJobs 和其他 pod 控制器被視為pod controller “pod 控制器”，因此，對 Pod 控制器的寫權限表示為?個虛擬的“control pod controller" “控制 Pod 控制器”權限，而不是實際的 21 種相關權限（例如，創建Deployment、更新update Deployment、修補patch Deployment、創建 CronJobs 等），

表 1 不可能包含 Kubernetes 中的所有強大權限，但它是我們所知的最完整的串列，還值得注意的是，我們還沒有研究其他“較弱”的攻擊類別，例如拒絕服務 (DoS)，

以下是每個攻擊類別的細分，

Acquire Tokens(獲取Tokens)

該組包含允許直接或間接檢索retrieve或頒發issue服務賬號SA令牌的權限，決定這些權限影響的主要因素是它們的范圍，無論它們是否是通過擁有強大服務賬號的特權命名空間授予的，默認情況下唯?具有特權的命名空間是 kube-system，但某些平臺可能會安裝其他特權命名空間，

權限包括：create pods(創建pods)，create secrets(創建secrets)，list secrets，update Deployment(更新Deployment)，create serviceAccount/token(創建SA或token)

攻擊示例

在 kube-system 命名空間中擁有 create serviceAccounts/token 權限的攻擊者可以通過 TokenRequests為預裝的強大服務賬號頒發新令牌，

遠程代碼執行

該組中的權限允許在 Pod 上執行代碼，也可能在節點上執行代碼，攻擊者不?定會通過濫用這些權限來提升權限——這取決于受攻擊的 Pod 或節點的權限，盡管如此，這些權限仍然會增加計算資源，并可能增加攻擊者控制下的業務邏輯，

權限包括：create pods/exec, create nodes/proxy, patch DaemonSets, create pods

攻擊示例

擁有 create pods/exec 權限的攻擊者可以在其他 pod 上執行代碼，例如通過 kubectl exec 提供的介面，

操作身份認證/授權Authentication/Authorization (AuthN/AuthZ)

該組中的權限允許操作身份驗證和授權，它們通常通過設計為授予權限或模擬其他身份等用例啟用權限升級，它們非常強大，用戶在授予它們時應格外小心，

攻擊示例

可以系結clusterrolebinding的攻擊者可以將預安裝的集群管理員cluster-admin這個cluster role集群角色授予其失陷的身份，

Steal Pods——竊取Pod

某些權限或權限組合可能允許攻擊者將 Pod 從一個節點竊取到另一個節點，為了使這種攻擊產生影響，攻擊者必須?先破壞他打算放置被盜 Pod 的節點，竊取 Pod 包含兩個步驟：驅逐 Pod，然后確保它落在您的節點上，為了最?限度地發揮影響，攻擊者會使用強大的服務賬號令牌來瞄準 Pod，

一項相似的攻擊——影響未來Pod調度——在報告中沒有包含，

權限包括： update nodes, create pods/eviction, delete pods, update nodes/status

更新node、創建Pod/驅逐、洗掉Pod、更新節點/狀態

攻擊示例

破壞節點并擁有更新節點權限的攻擊者可以從其他節點竊取 Pod 到其受損節點上，通過向目標節點添加具有 NoExecute 效果的污點，攻擊者可以強制 Kubernetes 驅逐并重新調度目標節點的 pod，通過向所有其他節點添加具有 NoSchedule 效果的污點，攻擊者可以確保將被逐出的 Pod 重新安排到其受感染的節點上，

值得注意的是，容忍 NoExecute 污點的 pod 不能通過這種技術被竊取，這些 Pod 并不常見，但?個流行的例子是 Calico 安裝的相當于管理員的“tigera-Operator”Pod，

據我們所知，利用NoExecute污點竊取 Pod 是一種新穎的攻擊技術，

Meddler-in-the-Middle——中間人攻擊

該組中的權限可能允許攻擊者對集群中的 Pod、節點或服務發起中間人攻擊，利用該組中的權限通常需要一些先決條件才能產生相對較弱的影響，此外，使用TLS 保護通信可以消除大多數中間人攻擊，

權限包括：update services/status, control endpointslices, patch pods/status

攻擊示例

擁有update services/status更新服務/狀態權限的攻擊者可以利?CVE-2020-8554通過負載均衡器 IP 將 Pod 和節點發送的流量從其預期目標重定向到現有端點，攻擊者必須控制現有端點才能成為有意義的攻擊，

容器逃逸和強大的DaemonSet:有毒的組合

當強大的權限被寬松授予時，它們更有可能落入壞人之手，在 Kubernetes 中，這可能以多種方式發生，但通過強大的 DaemonSet 和容器逃逸(container escape)最容易看到，

當強大的 DaemonSet 在集群中的每個節點上分發強大的令牌時，容器逃逸的利用危害會急劇增加，安裝了強大的 DaemonSets 后，成功逃離容器的攻擊者?定會中大獎——在受感染的節點上獲得強大的憑據，

我們使?“Trampoline pods”作為強大pods的同義詞，這個名字表明了它們的影響：設法破壞 Trampoline Pod 或其節點的攻擊者可以濫用其令牌在集群中橫向，破壞其他節點并獲得更高的權限，并非所有Trampoline pods都提供相同的彈力，根據權限的不同，某些權限可能允許攻擊者危害整個集群，而其他權限則可能僅在某些情況下被濫用，

運行一些功能強大的Pod是合理的，強大的權限存在是有原因的：有時需要它們，不作為 DaemonSet 的?部分運行的強大 pod 可以通過多種方法（在“Recommendations”建議中描述）與不受信任和公開暴露的 pod 隔離，即使沒有積極采取措施隔離它們，非DaemonSet Trampolines 也不太可能出現在特定的受感染節點上，

Trampoline DaemonSets 之所以成為安全問題的主要原因是強大憑證的分發，借助強大的 DaemonSet，集群中的每個節點都擁有強大的憑據，這意味著成功逃脫容器的攻擊者一定能在受感染的節點上找到強大的令牌，

節點默認不是powerful嗎？

如果沒有強大的 DaemonSet，節點上唯一可用的集群憑據屬于節點代理——Kubelet，2017 年，Kubernetes 通過發布NodeRestriction解決了源于Kubelet權限的權限提升攻擊準入控制器，NodeRestriction將Kubelet的權限限制為已系結到其節點的資源，例如在其之上運行的Pod，因此，node無法提升權限或成為集群管理員，因此如果沒有 Trampoline Pod，容器逃逸不足以接管整個集群，

值得注意的是，NodeRestiction 并不完美 - Kubelet 仍然可以讀取大多數集群物件、繞過出口網路策略、發起某些拒絕服務 (DoS) 攻擊，甚至對 pod 支持的服務發起 Meddler 中間人攻擊，雖然這些都是可能的，但重要的是要區分哪些權限可以對某些配置進行低嚴重性攻擊，哪些權限可以可靠地濫用以升級權限并危害集群，

下?節將介紹流行Kubernetes 平臺中的 Trampoline DaemonSet，如果 DaemonSet 只啟?低嚴重性或不可靠的攻擊（包括 Kubelet 可以獨立執行的攻擊），我們并不認為 DaemonSet 很強大，只有當守護行程的權限實際上可以導致整個集群受到損害時，它們才被認為是強大的，

流行Kubernetes平臺中強大的DaemonSet

為了了解強大權限的普遍性和現實世界的影響，Prisma Cloud 研究人員分析了八種流行的 Kubernetes 平臺，并尋找以強大權限運行的 DaemonSet，表2：被分析的8個k8s平臺

在檢查的 Kubernetes 平臺中，62.5% 默認安裝了強大的 DaemonSet，而另外 12.5% 的平臺也啟用了推薦功能，圖8：分析的8個 Kubernetes 平臺中流行的 DaemonSet

表3：被分析的k8s平臺中強大的DaemonSet

容器逃逸影響范圍

根據已確定的強大DaemonSet，在 50% 的 Kubernetes 平臺中，審查的單個容器逃逸足以危及整個集群，另外 12.5% 的情況下，容器逃逸可能足以接管?些集群，對于 12.5% 的平臺來說，如果啟用了推薦的功能，容器逃逸就足以危及整個集群，圖9：所分析的k8s平臺中容器逃逸的影響

在某些平臺中，DaemonSet 擁有與管理員等效的權限，這意味著濫用它們來獲取管理員權限非常簡單，在其他平臺中，DaemonSet 的功能不足以自行成為完全管理員，但它們確實擁有允許接管其他 Pod 的權限，在大多數這些平臺中，由于默認安裝了與管理員等效的 Pod，因此攻擊者仍然可以濫用平臺的 DaemonSet 來獲取管理員權限，

例如，在 Antrea 中，antrea-agent DaemonSet 的功能不足以單獨獲得管理員權限，但它確實擁有強大的權限，可以接管其他 pod，由于 Antrea 默認安裝了?個與管理員等效的 pod，因此 antrea-controller、antrea-agent 的權限仍然可能被利用，通過濫用它們來危害 antrea-controller pod 來獲取管理員權限，

表4：容器逃逸對分析平臺的影響

如果您的集群依賴于受影響的平臺之一，請不要驚慌，原因如下：

1. 要濫用強大的 DaemonSet，攻擊者首先需要妥協，然后逃離容器，
2. 一些平臺已經發布了取消強大DaemonSet 特權的版本，
3. 最佳實踐強化可以防止某些攻擊，例如，容器鏡像的允許串列策略可以阻止橫向移動攻擊，這些攻擊濫用更新pod“patch Pod”權限，用攻擊者控制的鏡像替換現有 Pod 的映像，
4. 話雖如此，如果您運行多租戶集群，您將面臨更大的風險，

“Escape == Admin”列中的“在某些集群中可能”表示容器逃逸的先決條件足以危害整個集群，但在某些集群中很可能會滿足，例如，攻擊者濫用可以竊取 Pod 的強大DaemonSet，只有在集群中存在可竊取的管理員權限的 Pod 時，才能獲取集群管理員權限，

例如，在 EKS 中，默認情況下沒有這樣的 pod，盡管如此，根據安裝管理等效 pod 的流行 Kubernetes 附加組件的絕對數量，許多野外集群很可能滿足這個先決條件，默認情況下安裝相當于 admin 的 pod 的?些流行專案包括 ingress-nginx、cert-manager、Kynvero、traefik 和 aws-load-balancer，

值得注意的是，Cilium 有兩種流行的安裝方法，上表適用于默認記錄的 cilium-cli，雖然默認的 Helm 安裝也部署了同樣強大的 DaemonSet 來接管其他 pod，但它沒有部署可以作為其目標的管理等效 pod，因此，當通過 Helm 安裝 Cilium 時，考慮到用戶安裝了相當于管理員的 pod（或者換句話說，“可能在某些集群中”），容器逃逸僅足以危及整個集群，

流行平臺中強大的Kubelet

雖然大多數 Kubernetes 發行版和托管服務都采用了 NodeRestriction 準入控制器，但有些仍然運行功能強大的
Kubelet，強大的 Kubelet 引入了與強大的 DaemonSet 相同的安全風險，受損的節點可以提升權限并接管集群的其余部分，

以下是所分析的托管服務和發行版中功能強大的 Kubelet 的細分，

受影響平臺的修復和緩解措施

我們在 2021 年 12 月至 2022 年 2 月期間向受影響的供應商和開源專案報告了已識別的強大DaemonSet 和 Kubelet，絕大多數平臺承諾剝奪其 Daemonst 的強大權限，其中?些平臺已經這樣做了，從原來的 62.5%，現在只剩下 25% 仍然運行強大的 DaemonSets，

平臺通過各種技術來處理強大的 DaemonSet，大多數人應用了以下三種解決方案中的一種或多種：

1.洗掉：某些權限被認為是不必要的，或者范圍太廣，因此被簡單地洗掉

2.重新放置：將需要強大權限的功能從在所有節點上運行的 DaemonSet 移動到在少數節點上運行的部署或控制平面，

3.限制：發布準入策略，將強大的 DaemonSet 限制為一些安全且預期的操作，

根據上述改進，單個容器逃逸足以危及整個集群的平臺數量從 50% 下降到僅 25%，請記住，這個數字與 Kubernetes 原生攻擊有關，不包括可能的針對特定平臺的權限提升，

剝奪現有權限可能具有挑戰性，我們要感謝本報告中提到的供應商和開源專案，感謝他們為從其平臺上洗掉強大的 DaemonSet 和 Kubelet 所做的努力，

實作更好的Node隔離

Kubernetes 正在一步步向更強的節點隔離邁進，這項作業從 NodeRestriction 準入控制器開始，并隨著從流行的 DaemonSet 中洗掉每個強大的權限而緩慢推進，在不久的將來，完全的節點隔離是不太可能的：一些低嚴重性的攻擊可能會繼續存在，并且某些節點將需要托管強大的 Pod，話雖如此，更好的節點隔離當然是可能的，至少，集群不應在每個節點上托管強大的憑據，洗掉 Trampoline DaemonSet 可以確保大多數節點沒有特權，

一些強大的權限將更難洗掉，部分原因是某些操作缺乏細粒度的訪問控制，但這不應該被視為“全有或全無”的問題，即使某些權限無法輕易剝奪，但當以前可以獲取管理令牌的 DaemonSet 現在只能發起中間人攻擊時，這仍然是一個值得歡迎的改進，

識別高權限

無論您是否使用上述平臺，如果您運行 Kubernetes，您的集群都可能托管功能強大（高權限）的 Pod，解決有風險的權限的第一步是識別它們，以下工具可用于識別正在運行的集群和 Kubernetes 清單中的強大權限，

rbac-police

我們很高興發布rbac-police，我們在整個研究中使用的工具來識別強大的權限，

rbac-police 是一個用Golang 撰寫的開源命令列界面 (CLI)，它檢索集群中 pod、節點和服務賬號的權限，并通過內置或自定義 Rego 策略對其進行評估，評估集群的 RBAC 狀態就像運行rbac-police eval lib?樣簡單，
下圖顯示了 rbac-police 輸出的一部分：圖 11： rbac-police 針對服務賬戶、Pod 和節點權限過多發出警報

rbac-police 開箱即用，配備了 20 多個策略，每個策略都會尋找一組不同的強大權限，不過它也是 100% 可定制的，您可以撰寫自己的策略來搜索 Kubernetes RBAC 中的任何模式 ——我們忽略的強大權限、僅影響某些平臺的權限或與 CRD （(Custom Resources Definitions自定義資源定義）相關的權限，如果您最終撰寫了政策，請考慮貢獻它，

rbac-police支持的命令如下：

• rbac-police eval 通過內置或自定義Rego 策略評估服務賬戶、Pod 和節點的RBAC 權限，
• rbac-police collect檢索集群中服務賬戶、Pod 和節點的RBAC權限，對于保存集群的 RBAC 快照以使?不同選項進行多次評估非常有用，
• rbac-police expand呈現服務賬戶、pod 和節點的 RBAC 權限以稍微更人性化的格式，對于手動深層探究很有用

對于微調評估，rbac-police 提供了多種選項，包括：

• --only-sa-on-all-nodes僅評估所有節點上存在的服務賬戶，對強大的 DaemonSets?份識別很有用
• --namespace, --ignored-namespaces將評估范圍限定為單個命名空間；忽略某些命名空間
• --severity-threshold僅評估嚴重性等于或大于閾值的策略，

此外，rbac-police 還支持評估節點有效權限的策略——其 Kubelet 權限和 pod 權限的聯合，一些更復雜的攻擊需要許多權限才能執行，因此，雖然沒有?個 pod 擁有執行攻擊所需的所有權限，但節點上的 pod 組合可能擁有執行攻擊所需的所有權限，

查看 rbac-police 的GitHub頁面了解更多資訊，如果您運行 Kubernetes，請考慮嘗試?下，它只需幾秒鐘即可運行，并提供有關 RBAC 狀態和可能風險的許多有價值的見解，

Checkov

checkov是 Bridgecrew 的?款開源靜態代碼分析工具，用于掃描基礎架構即代碼 (IaC) 檔案以查找可能導致安全或合規性問題的錯誤配置， Checkov 通過在錯誤配置提交到生產環境之前發出警報來左移安全能力，

我們貢獻了4個新的RBAC檢查，對包含定義了高權限的角色或集群角色發出告警：CKV_K8S_155、CKV_K8S_156、CKV_K8S_157 和 CKV_K8S_158

這些重點關注可以被濫用以操作身份認證和授權(如impersonation模擬)的高權限，

Checkov目前正在添加對圖形檢查的支持，可以評估多個 Kubernetes 資源之間的連接，該功能發布后，預計會添加更多 RBAC 檢查，

查看Checkov網站了解更多資訊

建議

處理高權限RBAC可能很復雜，因為它們很容易被忽略，且經常被第三方附加組件或底層基礎設定訪問，即使你管理功能強大的組件，洗掉權限也并不總是那么簡單，通常涉及代碼更改，

無論運行k8s集群或者維護流行的k8s專案，以下都是可以改善您的RBAC狀態的最佳實踐和強化措施

1. 遵循最小權限原則：僅分配明確需要的權限

   a.如果可能，用RoleBinding角色系結來對某個命名空間下賦予權限而不是集群范圍，

   b.用資源名稱resourceNames縮小特定資源的權限范圍

2. 跟蹤強大的的權限并且保證它們不被授予不太受信任或公開暴露的Pod，如果要維護k8s專案，需要詳細記錄平臺要求的高權限，

3. 避免運行高權限的 DaemonSet：

   a. 將需要強大權限的功能從所有節點上運行的 DaemonSet 移至在少數或控制平面控制上運行deployment

   b. 依賴 Kubelet 憑證來執行僅涉及系結到本地節點的物件的操作，例如檢索相鄰 Pod 的secrets，

   c. 通過在CRDs和ConfigMaps中的狀態存盤來最小化寫入權限，而不是在核心物件如Pod中

4. 使用調度約束將強大的 pod 與不受信任或公開暴露的 pod 隔離，例如污點和容忍制度，NodeAffinity規則，或PodAntiAfinity規則

5. 配置policy controller 策略控制器對自動身份發出告警（例如通過SelfSubjectReviews API查詢權限的SA和node）

6. 配置策略控制器以檢測或防止濫用強大權限進行惡意活動，濫用強大權限通常與正常使用不同，有關更多詳細資訊，請參閱下面的示例，

通過準入控制檢測攻擊

通常，受損的憑證會表現出不常規的行為，并為防御者提供識別違規行為的機會，在 Kubernetes 中，準入控制可以檢測并防止由受損憑證和特權權限發起的攻擊， OPA Gatekeeper和Kynvero等策略控制器可以強制執行策略，阻止或警告對 Kubernetes API 的可疑請求，以下是使用OPA Gatekeeper 的此方法的兩個示例，

可疑的SefSubjectReview

憑據盜竊后的常見攻擊者模式是查詢系統以獲取其權限，在 Kubernetes 中，這是通過 SelfSubjectAccessReview 或 SelfSubjectRulesReview API 完成的，非人類身份（例如 serviceAccounts 和查詢這些 API 權限的節點）是妥協的強烈跡象，檢測這些請求的策略提供了捕獲受損憑據的絕佳機會，

這是?個策略示例 用于檢測此類查詢的OPA Gatekeeper，

控制器服務賬戶SA的可疑分配

默認情況下，kube-system 命名空間托管多個與管理員等效的服務賬戶，這些賬戶由作為 api-server 的?部分運行的控制器使用，可以在 kube-system 命名空間中創建 pod 或 pod 控制器，或者修改 kube-system 命名空間中的 pod 控制器的攻擊者，可以將這些與管理員等效的服務賬號之?分配給他們控制的 pod，并濫用其強大的令牌來獲得集群的完全控制，

在前面介紹的"對高權限k8s權限分類""Classifying Powerful Kubernetes Permissions"框架中，這種攻擊被分類在Acquire Tokens獲取令牌中，

控制器服務賬戶通常不會分配給正在運行的 Pod，防御者可以利用這一點來檢測這種權限提升攻擊，并通過策略對將控制器服務賬戶附加到現有的或新kube-system pod 的請求發出警報，我們為 OPA Gatekeeper 撰寫了一個示例，可以在此獲取

結論

正如本報告所述，過多的 RBAC 權限很常見，很容易被忽視，并且可能導致針對 Kubernetes 集群的影響較大的權限提升攻擊，同時，強化的 RBAC 設定可以強制執行最低權限、阻止意外訪問并挫傷攻擊者的士氣，

由于 Kubernetes 的動態特性以及通常用于操作現代集群的第三方插件的數量，保持安全的 RBAC 狀態具有挑戰性，有關rbac-police等工具，請參閱“識別高權限”部分，它可以評估您的 RBAC 狀態，并參閱“建議”部分，了解即使集群中仍然存在一些強大的 pod，也可以最大限度地降低風險并阻止攻擊的方法，

我們要感謝本報告中提到的供應商和開源專案的合作以及他們為最大限度地減少平臺上強大憑證的分發所做努力，

附錄A: 按照攻擊類別劃分的高權限

Manipulate Authentication/Authorization (AuthN/AuthZ)

操作身份認證/授權

模擬用戶/組/服務賬號SA

模擬其他身份，例如用戶、組、服務賬號SA

role/cluster role提權

向現有role/clusterrole添加任意權限

系結rolebinding/clusterrole binding

將現有的role/cluster role授予任意身份

批準signer&更新證書簽名請求/批準

approve signers & update certificatesigningrequests/approval
Have an existing signer approve a certificatesigningrequest.

讓現有簽名者批準證書簽名請求

控制修改webhooks

修改已授權的角色或集群角色，

指的是在 Kubernetes 的準入程序中能夠對資源進行操作或修改的能力，當在 Kubernetes 中創建或修改資源時，準入控制器可以攔截請求，并在允許請求繼續之前應用額外的邏輯或修改，

在這個背景關系中，"修改已授權的角色和集群角色"意味著"變異的"Webhook 能夠修改已授權或允許特定資源的角色和集群角色，這使得 Webhook 能夠根據特定條件或要求動態修改與資源相關的權限和訪問控制設定，

Acquire Tokens獲取令牌

list secrets

檢索命名空間中現有服務賬號SA的服務賬號令牌SA token，

這項攻擊在將來通過Kubernetes增強提案(KEP)2799來解決：減少基于服務賬號Token的Secret

create secrets

為現有服務賬號下發新的服務賬號令牌，

create ServiceAccount/Token

通過TokenRequests為現有服務賬號下發臨時服務賬號Token

create pods

將現有服務賬號分配給新的Pod，允許該Pod獲取其Token，或者，將現有服務賬號令牌的secret token作為環境變數或卷掛載到新的Pod中

控制Pod Controller

將現有的服務賬號分配給新的或已存在的Pod，允許這些pod訪問Token，或者，將現有服務賬號令牌的secret token作為環境變數或卷掛載到新的或已存在的Pod中

控制用于驗證的webhook

在創建令牌時獲取令牌，例如，在為新服務賬號創建token secret時，

控制修改webhook

在創建令牌時獲取令牌，例如為新服務賬號創建token secret時，將服務賬號Token附加到新的Pod中

遠程代碼執行

create pods/exec

通過API Server在現有的Pod中執行命令

更新pod或臨時容器

ephermeralcontainer臨時容器

https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/ephemeral-containers/

將新容器附加到一個現有的Pod以在其上執行代碼，將容器賦予在底層節點上執行代碼的特權，

創建node節點或proxy代理

通過kubelet在現有pod中執行命令，

控制pods

通過修改現有pod替換container的鏡像，創建一個新的特權pod以在節點上執行代碼，

控制pods controller

通過Deployment等pod控制器自由創建或修改pods，通過設定容器為特權容器在node節點上執行代碼，

控制修改過的webhook

修改已授權的pod并通過替換一個或多個容器的鏡像、命令、引數、環境變數或掛載目錄來執行代碼，

Steal Pod

更改nodes

通過設定污點節點為NoExecute效果來驅逐一個pod，通過標記其他節點為unsheduled（例如NoSchedule污點），確保它的替換pod（假定pod是由ReplicaSets管理）會運行在特定的節點上，

更改Nodes/status狀態

將節點標記為unschedule，例如將其Pod容忍度置為0

創建pods/eviction驅逐

驅逐一個pod，主要為了類似ReplicaSets的控制器能夠重新生成它

洗掉pods

洗掉一個pod，為了類似ReplicaSets的控制器能夠重新生成它

洗掉nodes

洗掉一個node來洗掉它所有的pods，導致類似ReplicaSets的控制器能夠重新生成它

更改pods/status狀態

將pod標簽與同一命名空間中現有的副本控制器(如ReplicaSet)的選擇器進行匹配，以欺騙其洗掉現有的副本，設定pod的就緒時間為副本中最早的時間，確保假的Pod不會正在被洗掉，

更改pod

將pod標簽匹配副本控制器的選擇器(如同一命名空間中的ReplicaSet)，以欺騙其洗掉現有副本，

中間人

控制endpoitslices

更改現有服務的endpointslices來重定向部分流量，為現有服務創建新的endpointslices以重定向其部分流量，

更改endpoits

修改現有服務的endpoints以將服務流量重定向到其他地方，此攻擊在配置為使用endpointslice而不是endpoint的集群上無效，

更改service/status

添加負載均衡器IP來利用CVE-2022-8554，并將來自pods和nodes的流量從其指定目標重定向到現有endpoints端點

修改pods/status

將Pod標簽與同一命名空間中的服務選擇器匹配，以攔截部分流量

修改pods

將Pod標簽與同一命名空間中的服務選擇器匹配，以攔截部分流量

創建服務

創建一個ExternalIP服務以利用CVE-2022-8554，將來自pods和nodes的流量從指定目標重定向到現有endpoints端點，

控制修改webhooks

修改新的已授權的服務、endpoints端點和endpointslice來重定向集群流量，

標籤：其他

上一篇：用寫代碼的方式畫圖-試下PlantUML吧

下一篇：返回列表