原文白皮書
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的這篇谷歌云漏洞賞金計(jì)劃2022Top7案例學(xué)習(xí)參考；其中5th Prize: Kubernetes Privilege Escalation: Excessive Permissions in Popular Platforms；這是一篇來(lái)自paloalto的白皮書。并沒(méi)有直接描述漏洞或者安全問(wèn)題，但是其揭示了諸多提供Kubernetes服務(wù)的公有云廠商在pods失陷后與特權(quán)下的"DaemonSets"容器產(chǎn)生的權(quán)限提升的火花，并給出了kubernetes權(quán)限配置安全合理性的檢測(cè)工具；Google認(rèn)為這對(duì)于Kubernetes生態(tài)有所裨益，因此給出了$17311的獎(jiǎng)勵(lì)

前言

近年來(lái)越來(lái)越多的用戶部署和使用，k8s使用量猛增。不安全的默認(rèn)配置是新興復(fù)雜平臺(tái)典型的成長(zhǎng)陣痛，k8s也是。但現(xiàn)在大多數(shù)k8s平臺(tái)已經(jīng)根除不安全的默認(rèn)配置，之前廣泛存在的未授權(quán)錯(cuò)誤配置（例如未授權(quán)的kubelet訪問(wèn)）已經(jīng)越來(lái)越少見(jiàn)。習(xí)慣通過(guò)簡(jiǎn)單的攻擊來(lái)破壞集群的攻擊者們可能對(duì)此提升不太滿意，但務(wù)實(shí)的攻擊者們開始著手目標(biāo)針對(duì)更微妙的問(wèn)題。

Unit 42團(tuán)隊(duì)最近在野目睹了這種趨勢(shì)，因?yàn)樗鼈儾东@了Siloscape樣本，一個(gè)迄今最復(fù)雜的k8s惡意軟件樣本，它將多個(gè)漏洞連接在一起，以危害Pod，逃逸并接管Node，最終獲取整個(gè)集群的控制權(quán)。這個(gè)樣本演示了一種以前從未在野見(jiàn)過(guò)的方法：在破壞一個(gè)node節(jié)點(diǎn)后，它會(huì)檢查節(jié)點(diǎn)是否有過(guò)多權(quán)限，如果沒(méi)有就不會(huì)繼續(xù)攻擊。

隨著相對(duì)簡(jiǎn)單的k8s攻擊失去關(guān)聯(lián)性，攻擊者開始瞄準(zhǔn)過(guò)多權(quán)限和RBAC錯(cuò)誤配置。

Kubernetes 基于角色的訪問(wèn)控制 (RBAC) 是 Kubernetes 中的主要授權(quán)?案，管理用戶、組、pod 和節(jié)點(diǎn)對(duì) Kubernetes 資源的權(quán)限

K8s RBAC配置具有強(qiáng)制最小權(quán)限訪問(wèn)以避免攻擊者的能力，但錯(cuò)誤配置很容易被忽視?？此剖芟薜臋?quán)限通常有強(qiáng)大的功能，如這個(gè)基本的問(wèn)題“哪些Pods可以提升權(quán)限？”很難回答。在本報(bào)告中旨在解決這個(gè)問(wèn)題。我們引入一個(gè)框架，該框架根據(jù)強(qiáng)大的權(quán)限所引發(fā)的攻擊對(duì)它們進(jìn)行分類；有數(shù)十個(gè)最強(qiáng)大的k8s權(quán)限映射；并發(fā)布rbac-police，這是一個(gè)開源工具可以識(shí)別K8s集群中高權(quán)限和提權(quán)路徑。

為了解高權(quán)限的普遍性和影響，我們分析了流行的 Kubernetes 平臺(tái)——托管服務(wù)、發(fā)行、CNI——尋找以過(guò)多權(quán)限運(yùn)行的基礎(chǔ)設(shè)施組件。在檢查的62.5%的k8s平臺(tái)中，強(qiáng)大的DaemonSet在集群中每個(gè)節(jié)點(diǎn)上發(fā)布了高權(quán)限憑證。因此在50%的平臺(tái)中，單個(gè)容器逃逸就足以危及整個(gè)集群。

DaemonSet 通常用于將基礎(chǔ)設(shè)施 Pod 部署到所有工作節(jié)點(diǎn)上。

我們與受影響的平臺(tái)合作解決這些問(wèn)題并剝奪過(guò)多的權(quán)限。原來(lái)運(yùn)行強(qiáng)大DaemonSet的62.5%只剩下25%。同樣，容器逃逸肯定會(huì)導(dǎo)致集群接管的平臺(tái)百分比從 50% 下降到僅 25%，而且很快還會(huì)有更多平臺(tái)出現(xiàn)這種情況。雖然這朝著正確的方向發(fā)展，但 RBAC 錯(cuò)誤配置和過(guò)多的權(quán)限在不久的將來(lái)可能仍然是 Kubernetes 的重大安全風(fēng)險(xiǎn)。

請(qǐng)繼續(xù)閱讀，以更好地了解RBAC風(fēng)險(xiǎn)以及如何通過(guò)開源?具和最佳實(shí)踐配置來(lái)解決這些風(fēng)險(xiǎn)。學(xué)習(xí)將 RBAC 從盲點(diǎn)轉(zhuǎn)變?yōu)轭~外的防御層。

執(zhí)行摘要

近年來(lái)，Kubernetes 平臺(tái)在安全性方面取得了重大進(jìn)展，消除了嚴(yán)重的錯(cuò)誤配置并建立了安全基線。由于容易受到直接攻擊的集群越來(lái)越少，威脅行為者開始適應(yīng)并尋找濫用更微妙問(wèn)題的技術(shù)。最近的惡意軟件樣本表明Kubernetes 威脅參與者開始針對(duì)過(guò)多的權(quán)限。

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

RBAC錯(cuò)誤配置很容易被忽略

看似受限的權(quán)限可能非常強(qiáng)大，在某些情況下，與集群管理相當(dāng)。因此，開源附加組件和基礎(chǔ)設(shè)施組件會(huì)無(wú)意中請(qǐng)求強(qiáng)大的權(quán)限，而用戶在沒(méi)有意識(shí)到對(duì)其集群安全性的全面影響的情況下授予了這些權(quán)限。

Prisma? Cloud 研究人員確定了數(shù)十種強(qiáng)大的 Kubernetes 權(quán)限（已知的和新穎的），并根據(jù)它們引發(fā)的攻擊將它們分類為五種主要的 Kubernetes 攻擊類型。

高權(quán)限廣泛存在

為了了解強(qiáng)大權(quán)限的普遍性，Prisma Cloud 研究人員分析了流行的 Kubernetes 平臺(tái)（托管服務(wù)、發(fā)行版和容器網(wǎng)絡(luò)接口 (CNI)），以識(shí)別強(qiáng)大的 DaemonSet，這些 DaemonSet 可以在集群中的每個(gè)節(jié)點(diǎn)上分發(fā)強(qiáng)大的憑據(jù)。

在檢查的 Kubernetes 發(fā)行版和托管服務(wù)中，75% 默認(rèn)運(yùn)行強(qiáng)大的 DaemonSet。其余 25% 的人在啟用推薦功能的情況下也這樣做了。檢查主流容器網(wǎng)絡(luò)接口(CNI)，50% 默認(rèn)安裝強(qiáng)大的 DaemonSet。

過(guò)多權(quán)限導(dǎo)致影響大的攻擊

當(dāng)松散地授予強(qiáng)大的權(quán)限時(shí)，它們更有可能落入壞人之手。在Kubernetes中。這可能以多種方式發(fā)生，但通過(guò)強(qiáng)大的DaemonSet和容器逃逸最容易看到。

當(dāng)強(qiáng)大的 DaemonSets 在每個(gè)節(jié)點(diǎn)上分配強(qiáng)大的令牌時(shí)，容器逃逸的危害范圍會(huì)急劇增加。根據(jù)已識(shí)別的DaemonSet，在所審查的50%的Kubernetes平臺(tái)中，單個(gè)容器逃逸足以危及整個(gè)集群。

在 12.5% 的平臺(tái)中，單個(gè)容器逃逸可能足以接管一些集群。對(duì)于另外 12.5% 的人來(lái)說(shuō)，如果啟用了推薦的功能，容器逃逸足以危及整個(gè)集群。

圖 2：所分析的 Kubernetes 平臺(tái)中容器逃逸的影響

RBAC錯(cuò)誤配置是可解決的

Prisma Cloud 研究人員與供應(yīng)商和開源項(xiàng)目合作，剝離過(guò)多的權(quán)限并減少?gòu)?qiáng)大憑據(jù)的分發(fā)。原來(lái)運(yùn)行強(qiáng)大DaemonSet的62.5%只剩下25%。同樣，容器逃逸保證導(dǎo)致集群接管的平臺(tái)數(shù)量從50%下降到僅25%。這表明RBAC錯(cuò)誤配置是可以解決的，并且強(qiáng)?的權(quán)限通常可以被刪除。它還強(qiáng)調(diào)了受審查的供應(yīng)商和開源項(xiàng)目對(duì)其平臺(tái)安全的承諾。

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

基于角色的訪問(wèn)控制101

Kubernetes RBAC 是?種授權(quán)方案，用于管理對(duì) Kubernetes 資源的訪問(wèn)。權(quán)限分為 Roles 或 ClusterRoles，并且可以通過(guò) RoleBindings 或 ClusterRoleBindings 授予用戶、組和服務(wù)賬號(hào)。通過(guò) RoleBindings 授予的權(quán)限僅限于命名空間，而通過(guò) ClusterRoleBindings 授予的權(quán)限實(shí)際上在集群范圍內(nèi)有效。

例如，下面的 ClusterRoleBinding 將“pod-reader”ClusterRole 授予“read er-sa”服務(wù)賬號(hào)SA。

“reader-sa”服務(wù)現(xiàn)在賬號(hào)已被授權(quán)執(zhí)行“pod-reader”ClusterRole 中l(wèi)ist的操作。

如上所示，K8s權(quán)限可以通過(guò)規(guī)則來(lái)表達(dá)，每個(gè)規(guī)則允許對(duì)一個(gè)或多個(gè)API組中一個(gè)或多個(gè)資源，執(zhí)行一個(gè)或多個(gè)動(dòng)作。上述規(guī)則允許在核心API組中l(wèi)ist列舉和get獲取pod。常見(jiàn)的動(dòng)作動(dòng)詞包括：

? get: retrieve a resource by name 根據(jù)名稱檢索資源
? list: retrieve all resources 檢索全部資源
? create: create a resource 創(chuàng)建資源
? update: replace an existing resource 替換現(xiàn)有資源
? patch: modify an existing resource 修改現(xiàn)有資源
? delete: delete a resource 刪除資源

如圖3所示，可以通過(guò)將Role和ClusterRole(也就是權(quán)限)綁定到Pod的服務(wù)賬號(hào)來(lái)授予Pod權(quán)限。分配了"reader-sa"服務(wù)賬號(hào)的Pod能夠檢索集群范圍內(nèi)的pod。

對(duì)高k8s權(quán)限進(jìn)行分類

攻擊者可能會(huì)濫用某些 Kubernetes 權(quán)限來(lái)升級(jí)權(quán)限、橫向移動(dòng)或獲得對(duì)集群更廣泛的控制。從現(xiàn)在開始，這些將被稱為“強(qiáng)大的權(quán)限”。

一些強(qiáng)大的權(quán)限幾乎相當(dāng)于集群管理員，而其他權(quán)限只能在特定場(chǎng)景下濫用以進(jìn)行有限的攻擊。為了在討論強(qiáng)大的權(quán)限時(shí)建立一個(gè)通用框架，我們根據(jù)它們所引發(fā)的攻擊將它們分為五種攻擊類型。

當(dāng)涉及到強(qiáng)大的權(quán)限時(shí)，范圍是關(guān)鍵。當(dāng)在整個(gè)集群上授予權(quán)限時(shí)，權(quán)限可以與管理員等效，但當(dāng)范圍僅限于命名空間或特定資源名稱時(shí)，權(quán)限是無(wú)害的。為了包含所有可能的強(qiáng)大權(quán)限，上表假設(shè)在集群范圍內(nèi)授予權(quán)限。

某些強(qiáng)大的權(quán)限會(huì)引發(fā)多種攻擊，因此會(huì)映射到多個(gè)攻擊類別。另一方面，一些更復(fù)雜的攻擊需要結(jié)合列出的權(quán)限才能執(zhí)行。不足以自行發(fā)起攻擊的權(quán)限被標(biāo)記為黃色。

為了避免不成比例的膨脹，表 1 匯總了類似的動(dòng)作和資源。更新update和補(bǔ)丁patch動(dòng)作聚合為虛擬的“modify”修改動(dòng)詞，而修改modify和創(chuàng)建create則組合稱為"control"控制。 DaemonSets、Deployments、CronJobs 和其他 pod 控制器被視為pod controller “pod 控制器”。因此，對(duì) Pod 控制器的寫權(quán)限表示為?個(gè)虛擬的“control pod controller" “控制 Pod 控制器”權(quán)限，而不是實(shí)際的 21 種相關(guān)權(quán)限（例如，創(chuàng)建Deployment、更新update Deployment、修補(bǔ)patch Deployment、創(chuàng)建 CronJobs 等）。

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

以下是每個(gè)攻擊類別的細(xì)分。

Acquire Tokens(獲取Tokens)

該組包含允許直接或間接檢索retrieve或頒發(fā)issue服務(wù)賬號(hào)SA令牌的權(quán)限。決定這些權(quán)限影響的主要因素是它們的范圍，無(wú)論它們是否是通過(guò)擁有強(qiáng)大服務(wù)賬號(hào)的特權(quán)命名空間授予的。默認(rèn)情況下唯?具有特權(quán)的命名空間是 kube-system，但某些平臺(tái)可能會(huì)安裝其他特權(quán)命名空間。

權(quán)限包括：create pods(創(chuàng)建pods)，create secrets(創(chuàng)建secrets)，list secrets，update Deployment(更新Deployment)，create serviceAccount/token(創(chuàng)建SA或token)

攻擊示例

在 kube-system 命名空間中擁有 create serviceAccounts/token 權(quán)限的攻擊者可以通過(guò) TokenRequests為預(yù)裝的強(qiáng)大服務(wù)賬號(hào)頒發(fā)新令牌。

遠(yuǎn)程代碼執(zhí)行

該組中的權(quán)限允許在 Pod 上執(zhí)行代碼，也可能在節(jié)點(diǎn)上執(zhí)行代碼。攻擊者不?定會(huì)通過(guò)濫用這些權(quán)限來(lái)提升權(quán)限——這取決于受攻擊的 Pod 或節(jié)點(diǎn)的權(quán)限。盡管如此，這些權(quán)限仍然會(huì)增加計(jì)算資源，并可能增加攻擊者控制下的業(yè)務(wù)邏輯。

權(quán)限包括：create pods/exec, create nodes/proxy, patch DaemonSets, create pods

攻擊示例

擁有 create pods/exec 權(quán)限的攻擊者可以在其他 pod 上執(zhí)行代碼，例如通過(guò) kubectl exec 提供的接口。

操作身份認(rèn)證/授權(quán)Authentication/Authorization (AuthN/AuthZ)

該組中的權(quán)限允許操作身份驗(yàn)證和授權(quán)。它們通常通過(guò)設(shè)計(jì)為授予權(quán)限或模擬其他身份等用例啟用權(quán)限升級(jí)。它們非常強(qiáng)大，用戶在授予它們時(shí)應(yīng)格外小心。

攻擊示例

可以綁定clusterrolebinding的攻擊者可以將預(yù)安裝的集群管理員cluster-admin這個(gè)cluster role集群角色授予其失陷的身份。

Steal Pods——竊取Pod

某些權(quán)限或權(quán)限組合可能允許攻擊者將 Pod 從一個(gè)節(jié)點(diǎn)竊取到另一個(gè)節(jié)點(diǎn)。為了使這種攻擊產(chǎn)生影響，攻擊者必須?先破壞他打算放置被盜 Pod 的節(jié)點(diǎn)。竊取 Pod 包含兩個(gè)步驟：驅(qū)逐 Pod，然后確保它落在您的節(jié)點(diǎn)上。為了最?限度地發(fā)揮影響，攻擊者會(huì)使用強(qiáng)大的服務(wù)賬號(hào)令牌來(lái)瞄準(zhǔn) Pod。

一項(xiàng)相似的攻擊——影響未來(lái)Pod調(diào)度——在報(bào)告中沒(méi)有包含。

權(quán)限包括： update nodes, create pods/eviction, delete pods, update nodes/status

更新node、創(chuàng)建Pod/驅(qū)逐、刪除Pod、更新節(jié)點(diǎn)/狀態(tài)

攻擊示例

破壞節(jié)點(diǎn)并擁有更新節(jié)點(diǎn)權(quán)限的攻擊者可以從其他節(jié)點(diǎn)竊取 Pod 到其受損節(jié)點(diǎn)上。通過(guò)向目標(biāo)節(jié)點(diǎn)添加具有 NoExecute 效果的污點(diǎn)，攻擊者可以強(qiáng)制 Kubernetes 驅(qū)逐并重新調(diào)度目標(biāo)節(jié)點(diǎn)的 pod。通過(guò)向所有其他節(jié)點(diǎn)添加具有 NoSchedule 效果的污點(diǎn)，攻擊者可以確保將被逐出的 Pod 重新安排到其受感染的節(jié)點(diǎn)上。

值得注意的是，容忍 NoExecute 污點(diǎn)的 pod 不能通過(guò)這種技術(shù)被竊取。這些 Pod 并不常見(jiàn)，但?個(gè)流行的例子是 Calico 安裝的相當(dāng)于管理員的“tigera-Operator”Pod。

據(jù)我們所知，利用NoExecute污點(diǎn)竊取 Pod 是一種新穎的攻擊技術(shù)。

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

該組中的權(quán)限可能允許攻擊者對(duì)集群中的 Pod、節(jié)點(diǎn)或服務(wù)發(fā)起中間人攻擊。利用該組中的權(quán)限通常需要一些先決條件才能產(chǎn)生相對(duì)較弱的影響。此外，使用TLS 保護(hù)通信可以消除大多數(shù)中間人攻擊。

權(quán)限包括：update services/status, control endpointslices, patch pods/status

攻擊示例

擁有update services/status更新服務(wù)/狀態(tài)權(quán)限的攻擊者可以利?CVE-2020-8554通過(guò)負(fù)載均衡器 IP 將 Pod 和節(jié)點(diǎn)發(fā)送的流量從其預(yù)期目標(biāo)重定向到現(xiàn)有端點(diǎn)。攻擊者必須控制現(xiàn)有端點(diǎn)才能成為有意義的攻擊。

容器逃逸和強(qiáng)大的DaemonSet:有毒的組合

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

當(dāng)強(qiáng)大的 DaemonSet 在集群中的每個(gè)節(jié)點(diǎn)上分發(fā)強(qiáng)大的令牌時(shí)，容器逃逸的利用危害會(huì)急劇增加。安裝了強(qiáng)大的 DaemonSets 后，成功逃離容器的攻擊者?定會(huì)中大獎(jiǎng)——在受感染的節(jié)點(diǎn)上獲得強(qiáng)大的憑據(jù)。

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

運(yùn)行一些功能強(qiáng)大的Pod是合理的。強(qiáng)大的權(quán)限存在是有原因的：有時(shí)需要它們。不作為 DaemonSet 的?部分運(yùn)行的強(qiáng)大 pod 可以通過(guò)多種方法（在“Recommendations”建議中描述）與不受信任和公開暴露的 pod 隔離。即使沒(méi)有積極采取措施隔離它們，非DaemonSet Trampolines 也不太可能出現(xiàn)在特定的受感染節(jié)點(diǎn)上。

Trampoline DaemonSets 之所以成為安全問(wèn)題的主要原因是強(qiáng)大憑證的分發(fā)。借助強(qiáng)大的 DaemonSet，集群中的每個(gè)節(jié)點(diǎn)都擁有強(qiáng)大的憑據(jù)，這意味著成功逃脫容器的攻擊者一定能在受感染的節(jié)點(diǎn)上找到強(qiáng)大的令牌。

節(jié)點(diǎn)默認(rèn)不是powerful嗎？

如果沒(méi)有強(qiáng)大的 DaemonSet，節(jié)點(diǎn)上唯一可用的集群憑據(jù)屬于節(jié)點(diǎn)代理——Kubelet。2017 年，Kubernetes 通過(guò)發(fā)布NodeRestriction解決了源于Kubelet權(quán)限的權(quán)限提升攻擊準(zhǔn)入控制器。NodeRestriction將Kubelet的權(quán)限限制為已綁定到其節(jié)點(diǎn)的資源，例如在其之上運(yùn)行的Pod。因此，node無(wú)法提升權(quán)限或成為集群管理員，因此如果沒(méi)有 Trampoline Pod，容器逃逸不足以接管整個(gè)集群。

值得注意的是，NodeRestiction 并不完美 - Kubelet 仍然可以讀取大多數(shù)集群對(duì)象、繞過(guò)出口網(wǎng)絡(luò)策略、發(fā)起某些拒絕服務(wù) (DoS) 攻擊，甚至對(duì) pod 支持的服務(wù)發(fā)起 Meddler 中間人攻擊。雖然這些都是可能的，但重要的是要區(qū)分哪些權(quán)限可以對(duì)某些配置進(jìn)行低嚴(yán)重性攻擊，哪些權(quán)限可以可靠地濫用以升級(jí)權(quán)限并危害集群。

下?節(jié)將介紹流行Kubernetes 平臺(tái)中的 Trampoline DaemonSet。如果 DaemonSet 只啟?低嚴(yán)重性或不可靠的攻擊（包括 Kubelet 可以獨(dú)立執(zhí)行的攻擊），我們并不認(rèn)為 DaemonSet 很強(qiáng)大。只有當(dāng)守護(hù)進(jìn)程的權(quán)限實(shí)際上可以導(dǎo)致整個(gè)集群受到損害時(shí)，它們才被認(rèn)為是強(qiáng)大的。

流行Kubernetes平臺(tái)中強(qiáng)大的DaemonSet

為了了解強(qiáng)大權(quán)限的普遍性和現(xiàn)實(shí)世界的影響，Prisma Cloud 研究人員分析了八種流行的 Kubernetes 平臺(tái)，并尋找以強(qiáng)大權(quán)限運(yùn)行的 DaemonSet。表2：被分析的8個(gè)k8s平臺(tái)

在檢查的 Kubernetes 平臺(tái)中，62.5% 默認(rèn)安裝了強(qiáng)大的 DaemonSet，而另外 12.5% 的平臺(tái)也啟用了推薦功能。圖8：分析的8個(gè) Kubernetes 平臺(tái)中流行的 DaemonSet

表3：被分析的k8s平臺(tái)中強(qiáng)大的DaemonSet

容器逃逸影響范圍

根據(jù)已確定的強(qiáng)大DaemonSet，在 50% 的 Kubernetes 平臺(tái)中，審查的單個(gè)容器逃逸足以危及整個(gè)集群。另外 12.5% 的情況下，容器逃逸可能足以接管?些集群。對(duì)于 12.5% 的平臺(tái)來(lái)說(shuō)，如果啟用了推薦的功能，容器逃逸就足以危及整個(gè)集群。圖9：所分析的k8s平臺(tái)中容器逃逸的影響

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

例如，在 Antrea 中，antrea-agent DaemonSet 的功能不足以單獨(dú)獲得管理員權(quán)限，但它確實(shí)擁有強(qiáng)大的權(quán)限，可以接管其他 pod。由于 Antrea 默認(rèn)安裝了?個(gè)與管理員等效的 pod，因此 antrea-controller、antrea-agent 的權(quán)限仍然可能被利用，通過(guò)濫用它們來(lái)危害 antrea-controller pod 來(lái)獲取管理員權(quán)限。

表4：容器逃逸對(duì)分析平臺(tái)的影響

如果您的集群依賴于受影響的平臺(tái)之一，請(qǐng)不要驚慌。原因如下：

1. 要濫用強(qiáng)大的 DaemonSet，攻擊者首先需要妥協(xié)，然后逃離容器。
2. 一些平臺(tái)已經(jīng)發(fā)布了取消強(qiáng)大DaemonSet 特權(quán)的版本。
3. 最佳實(shí)踐強(qiáng)化可以防止某些攻擊。例如，容器鏡像的允許列表策略可以阻止橫向移動(dòng)攻擊，這些攻擊濫用更新pod“patch Pod”權(quán)限，用攻擊者控制的鏡像替換現(xiàn)有 Pod 的映像。
4. 話雖如此，如果您運(yùn)行多租戶集群，您將面臨更大的風(fēng)險(xiǎn)。

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

例如，在 EKS 中，默認(rèn)情況下沒(méi)有這樣的 pod。盡管如此，根據(jù)安裝管理等效 pod 的流行 Kubernetes 附加組件的絕對(duì)數(shù)量，許多野外集群很可能滿足這個(gè)先決條件。默認(rèn)情況下安裝相當(dāng)于 admin 的 pod 的?些流行項(xiàng)目包括 ingress-nginx、cert-manager、Kynvero、traefik 和 aws-load-balancer。

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

流行平臺(tái)中強(qiáng)大的Kubelet

雖然大多數(shù) Kubernetes 發(fā)行版和托管服務(wù)都采用了 NodeRestriction 準(zhǔn)入控制器，但有些仍然運(yùn)行功能強(qiáng)大的
Kubelet。強(qiáng)大的 Kubelet 引入了與強(qiáng)大的 DaemonSet 相同的安全風(fēng)險(xiǎn)。受損的節(jié)點(diǎn)可以提升權(quán)限并接管集群的其余部分。

以下是所分析的托管服務(wù)和發(fā)行版中功能強(qiáng)大的 Kubelet 的細(xì)分。

受影響平臺(tái)的修復(fù)和緩解措施

我們?cè)?2021 年 12 月至 2022 年 2 月期間向受影響的供應(yīng)商和開源項(xiàng)目報(bào)告了已識(shí)別的強(qiáng)大DaemonSet 和 Kubelet。絕大多數(shù)平臺(tái)承諾剝奪其 Daemonst 的強(qiáng)大權(quán)限，其中?些平臺(tái)已經(jīng)這樣做了。從原來(lái)的 62.5%，現(xiàn)在只剩下 25% 仍然運(yùn)行強(qiáng)大的 DaemonSets。

平臺(tái)通過(guò)各種技術(shù)來(lái)處理強(qiáng)大的 DaemonSet。大多數(shù)人應(yīng)用了以下三種解決方案中的一種或多種：

1.刪除：某些權(quán)限被認(rèn)為是不必要的，或者范圍太廣，因此被簡(jiǎn)單地刪除

2.重新放置：將需要強(qiáng)大權(quán)限的功能從在所有節(jié)點(diǎn)上運(yùn)行的 DaemonSet 移動(dòng)到在少數(shù)節(jié)點(diǎn)上運(yùn)行的部署或控制平面。

3.限制：發(fā)布準(zhǔn)入策略，將強(qiáng)大的 DaemonSet 限制為一些安全且預(yù)期的操作。

根據(jù)上述改進(jìn)，單個(gè)容器逃逸足以危及整個(gè)集群的平臺(tái)數(shù)量從 50% 下降到僅 25%。請(qǐng)記住，這個(gè)數(shù)字與 Kubernetes 原生攻擊有關(guān)，不包括可能的針對(duì)特定平臺(tái)的權(quán)限提升。

剝奪現(xiàn)有權(quán)限可能具有挑戰(zhàn)性。我們要感謝本報(bào)告中提到的供應(yīng)商和開源項(xiàng)目，感謝他們?yōu)閺钠淦脚_(tái)上刪除強(qiáng)大的 DaemonSet 和 Kubelet 所做的努力。

實(shí)現(xiàn)更好的Node隔離

Kubernetes 正在一步步向更強(qiáng)的節(jié)點(diǎn)隔離邁進(jìn)。這項(xiàng)工作從 NodeRestriction 準(zhǔn)入控制器開始，并隨著從流行的 DaemonSet 中刪除每個(gè)強(qiáng)大的權(quán)限而緩慢推進(jìn)。在不久的將來(lái)，完全的節(jié)點(diǎn)隔離是不太可能的：一些低嚴(yán)重性的攻擊可能會(huì)繼續(xù)存在，并且某些節(jié)點(diǎn)將需要托管強(qiáng)大的 Pod。話雖如此，更好的節(jié)點(diǎn)隔離當(dāng)然是可能的。至少，集群不應(yīng)在每個(gè)節(jié)點(diǎn)上托管強(qiáng)大的憑據(jù)。刪除 Trampoline DaemonSet 可以確保大多數(shù)節(jié)點(diǎn)沒(méi)有特權(quán)。

一些強(qiáng)大的權(quán)限將更難刪除，部分原因是某些操作缺乏細(xì)粒度的訪問(wèn)控制。但這不應(yīng)該被視為“全有或全無(wú)”的問(wèn)題。即使某些權(quán)限無(wú)法輕易剝奪，但當(dāng)以前可以獲取管理令牌的 DaemonSet 現(xiàn)在只能發(fā)起中間人攻擊時(shí)，這仍然是一個(gè)值得歡迎的改進(jìn)。

識(shí)別高權(quán)限

無(wú)論您是否使用上述平臺(tái)，如果您運(yùn)行 Kubernetes，您的集群都可能托管功能強(qiáng)大（高權(quán)限）的 Pod。解決有風(fēng)險(xiǎn)的權(quán)限的第一步是識(shí)別它們。以下工具可用于識(shí)別正在運(yùn)行的集群和 Kubernetes 清單中的強(qiáng)大權(quán)限。

rbac-police

我們很高興發(fā)布rbac-police，我們?cè)谡麄€(gè)研究中使用的工具來(lái)識(shí)別強(qiáng)大的權(quán)限。

rbac-police 是一個(gè)用Golang 編寫的開源命令行界面 (CLI)，它檢索集群中 pod、節(jié)點(diǎn)和服務(wù)賬號(hào)的權(quán)限，并通過(guò)內(nèi)置或自定義 Rego 策略對(duì)其進(jìn)行評(píng)估。評(píng)估集群的 RBAC 狀態(tài)就像運(yùn)行rbac-police eval lib?樣簡(jiǎn)單。
下圖顯示了 rbac-police 輸出的一部分：圖 11： rbac-police 針對(duì)服務(wù)賬戶、Pod 和節(jié)點(diǎn)權(quán)限過(guò)多發(fā)出警報(bào)

rbac-police 開箱即用，配備了 20 多個(gè)策略，每個(gè)策略都會(huì)尋找一組不同的強(qiáng)大權(quán)限。不過(guò)它也是 100% 可定制的。您可以編寫自己的策略來(lái)搜索 Kubernetes RBAC 中的任何模式 ——我們忽略的強(qiáng)大權(quán)限、僅影響某些平臺(tái)的權(quán)限或與 CRD （(Custom Resources Definitions自定義資源定義）相關(guān)的權(quán)限。如果您最終編寫了政策，請(qǐng)考慮貢獻(xiàn)它。

rbac-police支持的命令如下：

• rbac-police eval 通過(guò)內(nèi)置或自定義Rego 策略評(píng)估服務(wù)賬戶、Pod 和節(jié)點(diǎn)的RBAC 權(quán)限。
• rbac-police collect檢索集群中服務(wù)賬戶、Pod 和節(jié)點(diǎn)的RBAC權(quán)限。對(duì)于保存集群的 RBAC 快照以使?不同選項(xiàng)進(jìn)行多次評(píng)估非常有用。
• rbac-police expand呈現(xiàn)服務(wù)賬戶、pod 和節(jié)點(diǎn)的 RBAC 權(quán)限以稍微更人性化的格式。對(duì)于手動(dòng)深層探究很有用

對(duì)于微調(diào)評(píng)估，rbac-police 提供了多種選項(xiàng)，包括：

• --only-sa-on-all-nodes僅評(píng)估所有節(jié)點(diǎn)上存在的服務(wù)賬戶。對(duì)強(qiáng)大的 DaemonSets?份識(shí)別很有用
• --namespace, --ignored-namespaces將評(píng)估范圍限定為單個(gè)命名空間；忽略某些命名空間
• --severity-threshold僅評(píng)估嚴(yán)重性等于或大于閾值的策略。

此外，rbac-police 還支持評(píng)估節(jié)點(diǎn)有效權(quán)限的策略——其 Kubelet 權(quán)限和 pod 權(quán)限的聯(lián)合。一些更復(fù)雜的攻擊需要許多權(quán)限才能執(zhí)行。因此，雖然沒(méi)有?個(gè) pod 擁有執(zhí)行攻擊所需的所有權(quán)限，但節(jié)點(diǎn)上的 pod 組合可能擁有執(zhí)行攻擊所需的所有權(quán)限。

查看 rbac-police 的GitHub頁(yè)面了解更多信息。如果您運(yùn)行 Kubernetes，請(qǐng)考慮嘗試?下。它只需幾秒鐘即可運(yùn)行，并提供有關(guān) RBAC 狀態(tài)和可能風(fēng)險(xiǎn)的許多有價(jià)值的見(jiàn)解。

Checkov

checkov是 Bridgecrew 的?款開源靜態(tài)代碼分析工具，用于掃描基礎(chǔ)架構(gòu)即代碼 (IaC) 文件以查找可能導(dǎo)致安全或合規(guī)性問(wèn)題的錯(cuò)誤配置。 Checkov 通過(guò)在錯(cuò)誤配置提交到生產(chǎn)環(huán)境之前發(fā)出警報(bào)來(lái)左移安全能力。

我們貢獻(xiàn)了4個(gè)新的RBAC檢查，對(duì)包含定義了高權(quán)限的角色或集群角色發(fā)出告警：CKV_K8S_155、CKV_K8S_156、CKV_K8S_157 和 CKV_K8S_158

這些重點(diǎn)關(guān)注可以被濫用以操作身份認(rèn)證和授權(quán)(如impersonation模擬)的高權(quán)限。

Checkov目前正在添加對(duì)圖形檢查的支持，可以評(píng)估多個(gè) Kubernetes 資源之間的連接。該功能發(fā)布后，預(yù)計(jì)會(huì)添加更多 RBAC 檢查。

查看Checkov網(wǎng)站了解更多信息

建議

處理高權(quán)限RBAC可能很復(fù)雜，因?yàn)樗鼈兒苋菀妆缓雎裕医?jīng)常被第三方附加組件或底層基礎(chǔ)設(shè)置訪問(wèn)。即使你管理功能強(qiáng)大的組件，刪除權(quán)限也并不總是那么簡(jiǎn)單，通常涉及代碼更改。

無(wú)論運(yùn)行k8s集群或者維護(hù)流行的k8s項(xiàng)目，以下都是可以改善您的RBAC狀態(tài)的最佳實(shí)踐和強(qiáng)化措施

1. 遵循最小權(quán)限原則：僅分配明確需要的權(quán)限

   a.如果可能，用RoleBinding角色綁定來(lái)對(duì)某個(gè)命名空間下賦予權(quán)限而不是集群范圍。

   b.用資源名稱resourceNames縮小特定資源的權(quán)限范圍

2. 跟蹤強(qiáng)大的的權(quán)限并且保證它們不被授予不太受信任或公開暴露的Pod。如果要維護(hù)k8s項(xiàng)目，需要詳細(xì)記錄平臺(tái)要求的高權(quán)限。

3. 避免運(yùn)行高權(quán)限的 DaemonSet：

   a. 將需要強(qiáng)大權(quán)限的功能從所有節(jié)點(diǎn)上運(yùn)行的 DaemonSet 移至在少數(shù)或控制平面控制上運(yùn)行deployment

   b. 依賴 Kubelet 憑證來(lái)執(zhí)行僅涉及綁定到本地節(jié)點(diǎn)的對(duì)象的操作，例如檢索相鄰 Pod 的secrets。

   c. 通過(guò)在CRDs和ConfigMaps中的狀態(tài)存儲(chǔ)來(lái)最小化寫入權(quán)限，而不是在核心對(duì)象如Pod中

4. 使用調(diào)度約束將強(qiáng)大的 pod 與不受信任或公開暴露的 pod 隔離，例如污點(diǎn)和容忍制度，NodeAffinity規(guī)則，或PodAntiAfinity規(guī)則

5. 配置policy controller 策略控制器對(duì)自動(dòng)身份發(fā)出告警（例如通過(guò)SelfSubjectReviews API查詢權(quán)限的SA和node）

6. 配置策略控制器以檢測(cè)或防止濫用強(qiáng)大權(quán)限進(jìn)行惡意活動(dòng)。濫用強(qiáng)大權(quán)限通常與正常使用不同。有關(guān)更多詳細(xì)信息，請(qǐng)參閱下面的示例。

通過(guò)準(zhǔn)入控制檢測(cè)攻擊

通常，受損的憑證會(huì)表現(xiàn)出不常規(guī)的行為，并為防御者提供識(shí)別違規(guī)行為的機(jī)會(huì)。在 Kubernetes 中，準(zhǔn)入控制可以檢測(cè)并防止由受損憑證和特權(quán)權(quán)限發(fā)起的攻擊。 OPA Gatekeeper和Kynvero等策略控制器可以強(qiáng)制執(zhí)行策略，阻止或警告對(duì) Kubernetes API 的可疑請(qǐng)求。以下是使用OPA Gatekeeper 的此方法的兩個(gè)示例。

可疑的SefSubjectReview

憑據(jù)盜竊后的常見(jiàn)攻擊者模式是查詢系統(tǒng)以獲取其權(quán)限。在 Kubernetes 中，這是通過(guò) SelfSubjectAccessReview 或 SelfSubjectRulesReview API 完成的。非人類身份（例如 serviceAccounts 和查詢這些 API 權(quán)限的節(jié)點(diǎn)）是妥協(xié)的強(qiáng)烈跡象。檢測(cè)這些請(qǐng)求的策略提供了捕獲受損憑據(jù)的絕佳機(jī)會(huì)。

這是?個(gè)策略示例 用于檢測(cè)此類查詢的OPA Gatekeeper。

控制器服務(wù)賬戶SA的可疑分配

默認(rèn)情況下，kube-system 命名空間托管多個(gè)與管理員等效的服務(wù)賬戶，這些賬戶由作為 api-server 的?部分運(yùn)行的控制器使用?？梢栽?kube-system 命名空間中創(chuàng)建 pod 或 pod 控制器，或者修改 kube-system 命名空間中的 pod 控制器的攻擊者，可以將這些與管理員等效的服務(wù)賬號(hào)之?分配給他們控制的 pod，并濫用其強(qiáng)大的令牌來(lái)獲得集群的完全控制。

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

控制器服務(wù)賬戶通常不會(huì)分配給正在運(yùn)行的 Pod。防御者可以利用這一點(diǎn)來(lái)檢測(cè)這種權(quán)限提升攻擊，并通過(guò)策略對(duì)將控制器服務(wù)賬戶附加到現(xiàn)有的或新kube-system pod 的請(qǐng)求發(fā)出警報(bào)。我們?yōu)?OPA Gatekeeper 編寫了一個(gè)示例，可以在此獲取

結(jié)論

正如本報(bào)告所述，過(guò)多的 RBAC 權(quán)限很常見(jiàn)，很容易被忽視，并且可能導(dǎo)致針對(duì) Kubernetes 集群的影響較大的權(quán)限提升攻擊。同時(shí)，強(qiáng)化的 RBAC 設(shè)置可以強(qiáng)制執(zhí)行最低權(quán)限、阻止意外訪問(wèn)并挫傷攻擊者的士氣。

由于 Kubernetes 的動(dòng)態(tài)特性以及通常用于操作現(xiàn)代集群的第三方插件的數(shù)量，保持安全的 RBAC 狀態(tài)具有挑戰(zhàn)性。有關(guān)rbac-police等工具，請(qǐng)參閱“識(shí)別高權(quán)限”部分，它可以評(píng)估您的 RBAC 狀態(tài)，并參閱“建議”部分，了解即使集群中仍然存在一些強(qiáng)大的 pod，也可以最大限度地降低風(fēng)險(xiǎn)并阻止攻擊的方法。

我們要感謝本報(bào)告中提到的供應(yīng)商和開源項(xiàng)目的合作以及他們?yōu)樽畲笙薅鹊販p少平臺(tái)上強(qiáng)大憑證的分發(fā)所做努力。

附錄A: 按照攻擊類別劃分的高權(quán)限

Manipulate Authentication/Authorization (AuthN/AuthZ)

操作身份認(rèn)證/授權(quán)

模擬用戶/組/服務(wù)賬號(hào)SA

模擬其他身份，例如用戶、組、服務(wù)賬號(hào)SA

role/cluster role提權(quán)

向現(xiàn)有role/clusterrole添加任意權(quán)限

綁定rolebinding/clusterrole binding

將現(xiàn)有的role/cluster role授予任意身份

批準(zhǔn)signer&更新證書簽名請(qǐng)求/批準(zhǔn)

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

讓現(xiàn)有簽名者批準(zhǔn)證書簽名請(qǐng)求

控制修改webhooks

修改已授權(quán)的角色或集群角色。

指的是在 Kubernetes 的準(zhǔn)入過(guò)程中能夠?qū)Y源進(jìn)行操作或修改的能力。當(dāng)在 Kubernetes 中創(chuàng)建或修改資源時(shí)，準(zhǔn)入控制器可以攔截請(qǐng)求，并在允許請(qǐng)求繼續(xù)之前應(yīng)用額外的邏輯或修改。

在這個(gè)上下文中，"修改已授權(quán)的角色和集群角色"意味著"變異的"Webhook 能夠修改已授權(quán)或允許特定資源的角色和集群角色。這使得 Webhook 能夠根據(jù)特定條件或要求動(dòng)態(tài)修改與資源相關(guān)的權(quán)限和訪問(wèn)控制設(shè)置。

Acquire Tokens獲取令牌

list secrets

檢索命名空間中現(xiàn)有服務(wù)賬號(hào)SA的服務(wù)賬號(hào)令牌SA token。

這項(xiàng)攻擊在將來(lái)通過(guò)Kubernetes增強(qiáng)提案(KEP)2799來(lái)解決：減少基于服務(wù)賬號(hào)Token的Secret

create secrets

為現(xiàn)有服務(wù)賬號(hào)下發(fā)新的服務(wù)賬號(hào)令牌。

create ServiceAccount/Token

通過(guò)TokenRequests為現(xiàn)有服務(wù)賬號(hào)下發(fā)臨時(shí)服務(wù)賬號(hào)Token

create pods

將現(xiàn)有服務(wù)賬號(hào)分配給新的Pod，允許該P(yáng)od獲取其Token?；蛘?，將現(xiàn)有服務(wù)賬號(hào)令牌的secret token作為環(huán)境變量或卷掛載到新的Pod中

控制Pod Controller

將現(xiàn)有的服務(wù)賬號(hào)分配給新的或已存在的Pod，允許這些pod訪問(wèn)Token?；蛘?，將現(xiàn)有服務(wù)賬號(hào)令牌的secret token作為環(huán)境變量或卷掛載到新的或已存在的Pod中

控制用于驗(yàn)證的webhook

在創(chuàng)建令牌時(shí)獲取令牌，例如，在為新服務(wù)賬號(hào)創(chuàng)建token secret時(shí)。

控制修改webhook

在創(chuàng)建令牌時(shí)獲取令牌，例如為新服務(wù)賬號(hào)創(chuàng)建token secret時(shí)，將服務(wù)賬號(hào)Token附加到新的Pod中

遠(yuǎn)程代碼執(zhí)行

create pods/exec

通過(guò)API Server在現(xiàn)有的Pod中執(zhí)行命令

更新pod或臨時(shí)容器

ephermeralcontainer臨時(shí)容器

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

將新容器附加到一個(gè)現(xiàn)有的Pod以在其上執(zhí)行代碼。將容器賦予在底層節(jié)點(diǎn)上執(zhí)行代碼的特權(quán)。

創(chuàng)建node節(jié)點(diǎn)或proxy代理

通過(guò)kubelet在現(xiàn)有pod中執(zhí)行命令。

控制pods

通過(guò)修改現(xiàn)有pod替換container的鏡像。創(chuàng)建一個(gè)新的特權(quán)pod以在節(jié)點(diǎn)上執(zhí)行代碼。

控制pods controller

通過(guò)Deployment等pod控制器自由創(chuàng)建或修改pods。通過(guò)設(shè)置容器為特權(quán)容器在node節(jié)點(diǎn)上執(zhí)行代碼。

控制修改過(guò)的webhook

修改已授權(quán)的pod并通過(guò)替換一個(gè)或多個(gè)容器的鏡像、命令、參數(shù)、環(huán)境變量或掛載目錄來(lái)執(zhí)行代碼。

Steal Pod

更改nodes

通過(guò)設(shè)置污點(diǎn)節(jié)點(diǎn)為NoExecute效果來(lái)驅(qū)逐一個(gè)pod。通過(guò)標(biāo)記其他節(jié)點(diǎn)為unsheduled（例如NoSchedule污點(diǎn)），確保它的替換pod（假定pod是由ReplicaSets管理）會(huì)運(yùn)行在特定的節(jié)點(diǎn)上。

更改Nodes/status狀態(tài)

將節(jié)點(diǎn)標(biāo)記為unschedule，例如將其Pod容忍度置為0

創(chuàng)建pods/eviction驅(qū)逐

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

刪除pods

刪除一個(gè)pod，為了類似ReplicaSets的控制器能夠重新生成它

刪除nodes

刪除一個(gè)node來(lái)刪除它所有的pods，導(dǎo)致類似ReplicaSets的控制器能夠重新生成它

更改pods/status狀態(tài)

將pod標(biāo)簽與同一命名空間中現(xiàn)有的副本控制器(如ReplicaSet)的選擇器進(jìn)行匹配，以欺騙其刪除現(xiàn)有的副本。設(shè)置pod的就緒時(shí)間為副本中最早的時(shí)間，確保假的Pod不會(huì)正在被刪除。

更改pod

將pod標(biāo)簽匹配副本控制器的選擇器(如同一命名空間中的ReplicaSet)，以欺騙其刪除現(xiàn)有副本。

中間人

控制endpoitslices

更改現(xiàn)有服務(wù)的endpointslices來(lái)重定向部分流量。為現(xiàn)有服務(wù)創(chuàng)建新的endpointslices以重定向其部分流量。

更改endpoits

修改現(xiàn)有服務(wù)的endpoints以將服務(wù)流量重定向到其他地方。此攻擊在配置為使用endpointslice而不是endpoint的集群上無(wú)效。

更改service/status

添加負(fù)載均衡器IP來(lái)利用CVE-2022-8554，并將來(lái)自pods和nodes的流量從其指定目標(biāo)重定向到現(xiàn)有endpoints端點(diǎn)

修改pods/status

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

修改pods

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

創(chuàng)建服務(wù)

創(chuàng)建一個(gè)ExternalIP服務(wù)以利用CVE-2022-8554，將來(lái)自pods和nodes的流量從指定目標(biāo)重定向到現(xiàn)有endpoints端點(diǎn)。

控制修改webhooks

修改新的已授權(quán)的服務(wù)、endpoints端點(diǎn)和endpointslice來(lái)重定向集群流量。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-529921.html

到了這里，關(guān)于翻譯|K8s權(quán)限提升: 集群中過(guò)多權(quán)限引發(fā)的安全問(wèn)題的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！