本文翻譯整理自：
https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/

背景

近些年針對kubernetes的攻擊呈現愈演愈烈之勢，一旦攻擊者在kubernetes叢集中站穩腳跟就會嘗試滲透叢集涉及的所有容器，尤其是針對訪問控制和隔離做的不夠好的叢集受到的損害也會越大。例如由unit 42研究人員檢測到的TeamTNT組織的惡意軟體Siloscape就是利用了洩露的AWS憑證或錯誤配置從而獲得了kubelet初始訪問許可權後批次部署挖礦木馬或竊取關鍵資訊如使用者名稱和密碼，組織機密和內部檔案，甚至控制叢集中託管的整個資料庫從而發起勒索攻擊。根據微步線上的統計上一次遭受其攻擊的IP地址90%以上屬於中國，因此需要安全人員及時關注並提前規避風險。Siloscape具體攻擊流程如圖1所示。

圖 1-Siloscape攻擊流程

Kubernetes叢集中所有的資源的訪問和變更都是透過kubernetes API Server的REST API實現的，所以叢集安全的關鍵點就在於如何識別並認證客戶端身份並且對訪問許可權的鑑定，同時K8S還透過准入控制的機制實現審計作用確保最後一道安全底線。除此之外K8S還配有一系列的安全機制（如Secret和Service Account等）共同實現叢集訪問控制的安全，具體請求如圖2所示：

圖 2-Kubernetes API請求

其中使用者所控制的kubectl即每個Node節點都會啟用的程式，可以把kubelet理解成【Server-Agent】架構中的agent，用來處理Master節點下發到本節點的任務，管理Pod和其中的容器，比如建立容器、Pod掛載資料卷、下載secret、獲取容器和節點狀態等工作。Kubelet會在API Server上註冊節點資訊，定期向Master彙報節點資源使用情況。如果沒有做好相關的許可權管控或其遭受了任何的攻擊都可能導致對k8s叢集更廣泛的危害。如以下圖3操作。

圖 3-Kubectl操作

K8S認證鑑權

認證階段（Authentication）

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

表 1-認證

其中X509是kubernetes元件間預設使用的認證方式，同時也是kubectl客戶端對應的kube-config中經常使用到的訪問憑證，是一種比較安全的認證方式。

鑑權階段（Authorization）

當API Server內部透過使用者認證後，就會執行使用者鑑權流程，即透過鑑權策略決定一個API呼叫是否合法，API Server目前支援以下鑑權策略

表 2-鑑權

其中Always策略要避免用於生產環境中，ABAC雖然功能強大但是難以理解且配置複雜逐漸被RBAC替代，如果RBAC無法滿足某些特定需求，可以自行編寫鑑權邏輯並透過Webhook方式註冊為kubernetes的授權服務，以實現更加複雜的授權規則。而Node鑑權策略主要是用於對kubelet發出的請求進行訪問控制，限制每個Node只訪問它自身執行的Pod及相關Service、Endpoints等資訊。

准入控制（Admission Control）

突破瞭如上認證和鑑權關卡之後，客戶端的呼叫請求還需要透過准入控制的層層考驗，才能獲得成功的響應，kubernetes官方標準的選項有30多個，還允許使用者自定義擴充套件。大體分為三類驗證型、修改型、混合型，顧名思義驗證型主要用於驗證k8s的資源定義是否符合規則，修改型用於修改k8s的資源定義，如新增label，一般執行在驗證型之前，混合型及兩者的結合。

AC以外掛的形式執行在API Server程式中，會在鑑權階段之後，物件被持久化etcd之前，攔截API Server的請求，對請求的資源物件執行自定義（校驗、修改、拒絕等）操作。

Kubelet認證鑑權

認證

Kubelet目前共有三種認證方式:

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

authentication:
    anonymous:
        enabled: true

2.webhook，這時可不配置客戶端證書

authentication:
    webhook:
      enabled: true

3.TLS認證，也是目前預設的認證方式，對kubelet 的 HTTPS 端點啟用 X509 客戶端證書認證。

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

然而在實際環境當你想要透過kubectl命令列訪問kubelet時，無法傳遞bearer tokens，所以無法使用webhook認證，這時只能使用x509認證。

鑑權

kubelet可配置兩種鑑權方式分別為AlwaysAllow和Webhook，預設的及安全模式AlwaysAllow，允許所有請求。而Webhook的鑑權過程時委託給API Server的，使用API Server一樣的預設鑑權模式即RBAC。

通常在實際環境中需要我們透過TBAC為使用者配置相關許可權，包括配置使用者組以及其相對應的許可權。並最終將使用者和角色繫結完成許可權的配置。

TLS bootstrapping

TLS在實際實現的時候成本較高，尤其叢集中眾多的kubelet都需要與kube-API Server通訊，如果由管理員管理證書及許可權，很有可能會因為證書過期等問題出現混亂。這時候Kubelet TLS Bootstrapping就應運而生了。其主要實現兩個功能第一，實現kubelet與kube-API Server之間的自動認證通訊；第二，限制相關訪問API Server的許可權。

K8s目前預設透過TLS bootstrapping這套機制為每個kubelet配置簽名證書確保與API Server的互動安全。其核心思想是由kubelet自已生成及向API Server提交自已的證書籤名請求檔案（CSR），k8s-master對CSR簽發後，kubelet再向API Server獲取自已的簽名證書，然後再正常訪問API Server。具體如圖所示：

圖 4-Kubelet TLS bootstrapping工作流程

Kubelet提權案例

攻擊路徑

為了演示kubelet提權攻擊，下面會展示一個簡單的攻擊場景，從獲取TLS引導憑據開始，最終獲得叢集中叢集管理員的訪問許可權。

攻擊步驟

由於Kubelet需要依據憑據與API伺服器通訊，當攻擊者已經控制了叢集中部分執行的容器後可以依託這些憑據訪問API伺服器，並透過提權等手段來造成更大的影響。

1、首先攻擊者需要獲取到Node許可權並找到kubelet TLS引導憑據，見下圖：

2、嘗試使用TLS憑證檢索有關kubernetes節點的資訊，由於這些憑據僅有建立和檢索證書籤名請求的許可權即引導憑據用來向控制端提交證書籤名請求（CSR）所以通常會看到找不到相關資源。

其中kubectl auth can-i子命令有助於確定當前憑證是否可以執行相關命令。

3、由於許可權不足，可以使用get csr嘗試成為叢集中的假工作節點，這樣將允許我們執行更多的命令如列出節點、服務和pod等，但是仍然無法獲取更高階別的資料。

我們使用cfssl為假節點生成CSR，同時將其提交至API Server供其自動批准該證書，通常情況下kube-controller-manager設定為自動批准與字首一致的簽名請求，併發出客戶證書，隨後該節點的kubelet即可用於常用功能。

4、之後我們將批准透過的證書儲存，此時即可檢視節點資訊等相關內容。

5、為了獲取更高的許可權，我們嘗試使用另一個工作節點生成新的CSR，並要求API Server自動透過該證書。

6、我們將新批准的證書儲存並以此證書檢查相關的pod資訊發現有了金鑰資訊，但是當我們嘗試去讀取的時候仍然顯示許可權不足。

7、我們再次嘗試其他pod看是否擁有更高階別的許可權，重複之前的證書製作併傳送至API Server請求批准，這次許可權明顯高了許多，我們成功獲取到了ca.crt以及token。

8、接下來我們嘗試使用該token，設定好環境變數並獲取預設名稱空間中的所有資源。

9、最後我們檢查其角色的繫結，發現該服務賬戶已於“cluster-admin”角色繫結。

即其為最高許可權的賬戶，至此我們可以執行各種不同的攻擊。如從工作節點的例項竊取服務賬戶令牌訪問雲資源、列出配置、建立特權容器、後門容器等。

Kubernetes具有廣泛的攻擊面，其中kubelet尤為重要，本案例透過洩露的憑據開始，透過列出相關節點、例項生成和提交CSR充當工作節點，並最終獲得叢集管理員訪問許可權從而竊取TLS Bootstrap憑據。

緩解措施

在實際生產環境中，一定要保護好kubelet憑證的資料避免類似的提權事件發生，同時還可以搭配以下幾點方式來加固k8s的安全。

1、保護好後設資料，後設資料由於其敏感性務必在服務後臺加強對後設資料讀取的管控，避免攻擊者透過後設資料讀取到相關憑據資訊，哪怕是低許可權的憑據。

2、透過更安全的網路策略避免類似提權事件發生，預設情況下拒絕所有出站通訊，然後根據需要將出站流量列入白名單。在pod上應用該網路策略，因為需要訪問API伺服器和後設資料的是node而不是pod。

3、啟用類似Istio這樣的服務網格並配置egress gateway，這將阻止部署在服務網格中的任何容器與任何未經授權的主機進行通訊

4、限制對主節點的網路訪問，如上案例基本都發生在叢集，所以傳統的vpn也無法阻止相關危害，使用者可以直接限制對主伺服器的訪問來避免k8s的許多攻擊。

參考文獻

1.https://www.cnblogs.com/huanglingfa/p/13773234.html

2.https://cloud.tencent.com/developer/article/1553947

3.https://kubernetes.io/zh/docs/reference/access-authn-authz/authentication/

4.https://mritd.com/2018/01/07/kubernetes-tls-bootstrapping-note/

雲上攻防往期推薦：

• 淺談雲上攻防——後設資料服務帶來的安全挑戰
  
• 淺談雲上攻防——Web應用託管服務中的後設資料安全隱患
  
• 淺談雲上攻防——物件儲存服務訪問策略評估機制研究