技術文章 » 翻譯|K8s許可權提升: 叢集中過多許可權引發的安全問題

翻譯|K8s許可權提升: 叢集中過多許可權引發的安全問題

2023-07-07 18:00:18

原文白皮書
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來重定向叢集流量。