背景

近些年針對kubernetes的攻擊呈現(xiàn)愈演愈烈之勢，一旦攻擊者在kubernetes集群中站穩(wěn)腳跟就會嘗試滲透集群涉及的所有容器，尤其是針對訪問控制和隔離做的不夠好的集群受到的損害也會越大。例如由unit 42研究人員檢測到的TeamTNT組織的惡意軟件Siloscape就是利用了泄露的AWS憑證或錯誤配置從而獲得了kubelet初始訪問權(quán)限后批量部署挖礦木馬或竊取關(guān)鍵信息如用戶名和密碼，組織機(jī)密和內(nèi)部文件，甚至控制集群中托管的整個(gè)數(shù)據(jù)庫從而發(fā)起勒索攻擊。根據(jù)微步在線的統(tǒng)計(jì)上一次遭受其攻擊的IP地址90%以上屬于中國，因此需要安全人員及時(shí)關(guān)注并提前規(guī)避風(fēng)險(xiǎn)。Siloscape具體攻擊流程如圖1所示。

Kubernetes集群中所有的資源的訪問和變更都是通過kubernetes API Server的REST API實(shí)現(xiàn)的，所以集群安全的關(guān)鍵點(diǎn)就在于如何識別并認(rèn)證客戶端身份并且對訪問權(quán)限的鑒定，同時(shí)K8S還通過準(zhǔn)入控制的機(jī)制實(shí)現(xiàn)審計(jì)作用確保最后一道安全底線。除此之外K8S還配有一系列的安全機(jī)制（如Secret和Service Account等）共同實(shí)現(xiàn)集群訪問控制的安全，具體請求如圖2所示：

圖 2-Kubernetes API請求

其中用戶所控制的kubectl即每個(gè)Node節(jié)點(diǎn)都會啟用的進(jìn)程，可以把kubelet理解成【Server-Agent】架構(gòu)中的agent，用來處理Master節(jié)點(diǎn)下發(fā)到本節(jié)點(diǎn)的任務(wù)，管理Pod和其中的容器，比如創(chuàng)建容器、Pod掛載數(shù)據(jù)卷、下載secret、獲取容器和節(jié)點(diǎn)狀態(tài)等工作。Kubelet會在API Server上注冊節(jié)點(diǎn)信息，定期向Master匯報(bào)節(jié)點(diǎn)資源使用情況。如果沒有做好相關(guān)的權(quán)限管控或其遭受了任何的攻擊都可能導(dǎo)致對k8s集群更廣泛的危害。如以下圖3操作。

圖 3-Kubectl操作

K8S認(rèn)證鑒權(quán)

認(rèn)證階段（Authentication）

認(rèn)證階段即判斷用戶是否為能夠訪問集群的合法用戶，API Server目前提供了三種策略多種用戶身份認(rèn)證方式，他們分別如下表1：

表 1-認(rèn)證

其中X509是kubernetes組件間默認(rèn)使用的認(rèn)證方式，同時(shí)也是kubectl客戶端對應(yīng)的kube-config中經(jīng)常使用到的訪問憑證，是一種比較安全的認(rèn)證方式。

鑒權(quán)階段（Authorization）

當(dāng)API Server內(nèi)部通過用戶認(rèn)證后，就會執(zhí)行用戶鑒權(quán)流程，即通過鑒權(quán)策略決定一個(gè)API調(diào)用是否合法，API Server目前支持以下鑒權(quán)策略

表 2-鑒權(quán)

其中Always策略要避免用于生產(chǎn)環(huán)境中，ABAC雖然功能強(qiáng)大但是難以理解且配置復(fù)雜逐漸被RBAC替代，如果RBAC無法滿足某些特定需求，可以自行編寫鑒權(quán)邏輯并通過Webhook方式注冊為kubernetes的授權(quán)服務(wù)，以實(shí)現(xiàn)更加復(fù)雜的授權(quán)規(guī)則。而Node鑒權(quán)策略主要是用于對kubelet發(fā)出的請求進(jìn)行訪問控制，限制每個(gè)Node只訪問它自身運(yùn)行的Pod及相關(guān)Service、Endpoints等信息。

準(zhǔn)入控制（Admission Control）

突破了如上認(rèn)證和鑒權(quán)關(guān)卡之后，客戶端的調(diào)用請求還需要通過準(zhǔn)入控制的層層考驗(yàn)，才能獲得成功的響應(yīng)，kubernetes官方標(biāo)準(zhǔn)的選項(xiàng)有30多個(gè)，還允許用戶自定義擴(kuò)展。大體分為三類驗(yàn)證型、修改型、混合型，顧名思義驗(yàn)證型主要用于驗(yàn)證k8s的資源定義是否符合規(guī)則，修改型用于修改k8s的資源定義，如添加label，一般運(yùn)行在驗(yàn)證型之前，混合型及兩者的結(jié)合。

AC以插件的形式運(yùn)行在API Server進(jìn)程中，會在鑒權(quán)階段之后，對象被持久化etcd之前，攔截API Server的請求，對請求的資源對象執(zhí)行自定義（校驗(yàn)、修改、拒絕等）操作。

Kubelet認(rèn)證鑒權(quán)

認(rèn)證

Kubelet目前共有三種認(rèn)證方式:

1.允許anonymous，這時(shí)可不配置客戶端證書

authentication: anonymous: enabled: true

2.webhook，這時(shí)可不配置客戶端證書

authentication: webhook: enabled: true

3.TLS認(rèn)證，也是目前默認(rèn)的認(rèn)證方式，對kubelet 的 HTTPS 端點(diǎn)啟用 X509 客戶端證書認(rèn)證。

authentication: anonymous: enabled: false webhook: enabled: false x509: clientCAFile: xxxx

然而在實(shí)際環(huán)境當(dāng)你想要通過kubectl命令行訪問kubelet時(shí)，無法傳遞bearer tokens，所以無法使用webhook認(rèn)證，這時(shí)只能使用x509認(rèn)證。

鑒權(quán)

kubelet可配置兩種鑒權(quán)方式分別為AlwaysAllow和Webhook，默認(rèn)的及安全模式AlwaysAllow，允許所有請求。而Webhook的鑒權(quán)過程時(shí)委托給API Server的，使用API Server一樣的默認(rèn)鑒權(quán)模式即RBAC。

通常在實(shí)際環(huán)境中需要我們通過TBAC為用戶配置相關(guān)權(quán)限，包括配置用戶組以及其相對應(yīng)的權(quán)限。并最終將用戶和角色綁定完成權(quán)限的配置。

TLS bootstrapping

TLS在實(shí)際實(shí)現(xiàn)的時(shí)候成本較高，尤其集群中眾多的kubelet都需要與kube-API Server通信，如果由管理員管理證書及權(quán)限，很有可能會因?yàn)樽C書過期等問題出現(xiàn)混亂。這時(shí)候Kubelet TLS Bootstrapping就應(yīng)運(yùn)而生了。其主要實(shí)現(xiàn)兩個(gè)功能第一，實(shí)現(xiàn)kubelet與kube-API Server之間的自動認(rèn)證通信；第二，限制相關(guān)訪問API Server的權(quán)限。

K8s目前默認(rèn)通過TLS bootstrapping這套機(jī)制為每個(gè)kubelet配置簽名證書確保與API Server的交互安全。其核心思想是由kubelet自已生成及向API Server提交自已的證書簽名請求文件（CSR），k8s-master對CSR簽發(fā)后，kubelet再向API Server獲取自已的簽名證書，然后再正常訪問API Server。具體如圖所示：

圖 4-Kubelet TLS bootstrapping工作流程

Kubelet提權(quán)案例

攻擊路徑

為了演示kubelet提權(quán)攻擊，下面會展示一個(gè)簡單的攻擊場景，從獲取TLS引導(dǎo)憑據(jù)開始，最終獲得集群中集群管理員的訪問權(quán)限。

攻擊步驟

由于Kubelet需要依據(jù)憑據(jù)與API服務(wù)器通信，當(dāng)攻擊者已經(jīng)控制了集群中部分運(yùn)行的容器后可以依托這些憑據(jù)訪問API服務(wù)器，并通過提權(quán)等手段來造成更大的影響。

1、首先攻擊者需要獲取到Node權(quán)限并找到kubelet TLS引導(dǎo)憑據(jù)，見下圖：

2、嘗試使用TLS憑證檢索有關(guān)kubernetes節(jié)點(diǎn)的信息，由于這些憑據(jù)僅有創(chuàng)建和檢索證書簽名請求的權(quán)限即引導(dǎo)憑據(jù)用來向控制端提交證書簽名請求（CSR）所以通常會看到找不到相關(guān)資源。

其中kubectl auth can-i子命令有助于確定當(dāng)前憑證是否可以執(zhí)行相關(guān)命令。

3、由于權(quán)限不足，可以使用get csr嘗試成為集群中的假工作節(jié)點(diǎn)，這樣將允許我們執(zhí)行更多的命令如列出節(jié)點(diǎn)、服務(wù)和pod等，但是仍然無法獲取更高級別的數(shù)據(jù)。

我們使用cfssl為假節(jié)點(diǎn)生成CSR，同時(shí)將其提交至API Server供其自動批準(zhǔn)該證書，通常情況下kube-controller-manager設(shè)置為自動批準(zhǔn)與前綴一致的簽名請求，并發(fā)出客戶證書，隨后該節(jié)點(diǎn)的kubelet即可用于常用功能。


4、之后我們將批準(zhǔn)通過的證書保存，此時(shí)即可查看節(jié)點(diǎn)信息等相關(guān)內(nèi)容。

5、為了獲取更高的權(quán)限，我們嘗試使用另一個(gè)工作節(jié)點(diǎn)生成新的CSR，并要求API Server自動通過該證書。


6、我們將新批準(zhǔn)的證書保存并以此證書檢查相關(guān)的pod信息發(fā)現(xiàn)有了密鑰信息，但是當(dāng)我們嘗試去讀取的時(shí)候仍然顯示權(quán)限不足。

7、我們再次嘗試其他pod看是否擁有更高級別的權(quán)限，重復(fù)之前的證書制作并發(fā)送至API Server請求批準(zhǔn)，這次權(quán)限明顯高了許多，我們成功獲取到了ca.crt以及token。

8、接下來我們嘗試使用該token，設(shè)置好環(huán)境變量并獲取默認(rèn)命名空間中的所有資源。


9、最后我們檢查其角色的綁定，發(fā)現(xiàn)該服務(wù)賬戶已于“cluster-admin”角色綁定。


即其為最高權(quán)限的賬戶，至此我們可以執(zhí)行各種不同的攻擊。如從工作節(jié)點(diǎn)的實(shí)例竊取服務(wù)賬戶令牌訪問云資源、列出配置、創(chuàng)建特權(quán)容器、后門容器等。

Kubernetes具有廣泛的攻擊面，其中kubelet尤為重要，本案例通過泄露的憑據(jù)開始，通過列出相關(guān)節(jié)點(diǎn)、實(shí)例生成和提交CSR充當(dāng)工作節(jié)點(diǎn)，并最終獲得集群管理員訪問權(quán)限從而竊取TLS Bootstrap憑據(jù)。

緩解措施

在實(shí)際生產(chǎn)環(huán)境中，一定要保護(hù)好kubelet憑證的數(shù)據(jù)避免類似的提權(quán)事件發(fā)生，同時(shí)還可以搭配以下幾點(diǎn)方式來加固k8s的安全。

1、保護(hù)好元數(shù)據(jù)，元數(shù)據(jù)由于其敏感性務(wù)必在服務(wù)后臺加強(qiáng)對元數(shù)據(jù)讀取的管控，避免攻擊者通過元數(shù)據(jù)讀取到相關(guān)憑據(jù)信息，哪怕是低權(quán)限的憑據(jù)。

2、通過更安全的網(wǎng)絡(luò)策略避免類似提權(quán)事件發(fā)生，默認(rèn)情況下拒絕所有出站通信，然后根據(jù)需要將出站流量列入白名單。在pod上應(yīng)用該網(wǎng)絡(luò)策略，因?yàn)樾枰L問API服務(wù)器和元數(shù)據(jù)的是node而不是pod。

3、啟用類似Istio這樣的服務(wù)網(wǎng)格并配置egress gateway，這將阻止部署在服務(wù)網(wǎng)格中的任何容器與任何未經(jīng)授權(quán)的主機(jī)進(jìn)行通信

4、限制對主節(jié)點(diǎn)的網(wǎng)絡(luò)訪問，如上案例基本都發(fā)生在集群，所以傳統(tǒng)的vpn也無法阻止相關(guān)危害，用戶可以直接限制對主服務(wù)器的訪問來避免k8s的許多攻擊。

有需要了解相關(guān)資料的朋友闊以關(guān)注私信我哦！！！

【詳細(xì)了解】

總結(jié)

以上是生活随笔為你收集整理的【攻防】Kubelet访问控制机制与提权方法研究的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。