淺談云上攻防—— Kubelet 訪問控制機制與提權方法研究

作者：云鼎實驗室
原文鏈接：https://mp.weixin.qq.com/s/qLEjK1sx6P2KG9YgGkxqJg

背景

本文翻譯整理自rhino安全實驗室：近些年針對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	匿名認證	Anonymous requests
2	白名單認證	BasicAuth認證
3	Token認證	Webhooks、Service Account Tokens、OpenID Connect Tokens等
4	X509證書認證	clientCA認證，TLS bootstrapping等

表 1-認證

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

鑒權階段（Authorization）

當API Server內部通過用戶認證后，就會執行用戶鑒權流程，即通過鑒權策略決定一個API調用是否合法，API Server目前支持以下鑒權策略

序號	鑒權策略	概述
1	Always	分為AlwaysDeny和AlwaysAllow，當集群不需要鑒權時選擇AlwaysAllow
2	ABAC	基于屬性的訪問控制
3	RBAC	基于角色的訪問控制
4	Node	一種對kubelet進行授權的特殊模式
5	Webhook	通過調用外部REST服務對用戶鑒權

表 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。具體如圖所示：