突發——K8s節點淪為礦工
9月8日，雲安全中心接到一位客戶的緊急求助，稱其部署在公有雲的K8s叢集遭到入侵，在數分鐘之内K8s節點全部淪陷，并被植入挖礦程式。阿裡雲雲安全中心對該惡意程序進行了緊急處置和隔離，并結合K8s審計日志以及雲安全中心主機側日志還原入侵鍊路，深入分析了此次事件的原因。
雲安全中心緊急防禦截屏
排查——鑒權配置不當
阿裡雲安全專家從主機日志出發，找到了攻擊者植入的惡意鏡像、腳本，根據行為判定——這是一次非定向的蠕蟲自動化入侵事件。随後通過對K8s審計日志的梳理找到了攻擊者IP，并根據這些IP濾出全部日志還原了入侵鍊路。
**本次入侵事件由K8s API Server鑒權不當導緻，攻擊者通過匿名使用者登入到cluster-admin組并對整個K8s叢集下發挖礦程式。**
雲服務商堵漏 vs 自建叢集失守
K8s API Server的鑒權問題由來已久。預設情況下K8s API Server會開啟兩個端口：8080(Localhost Port)和 6443(Secure Port)，其中8080端口為WEB UI Dashboard，無需認證，用于本地測試與監控；6443端口需要認證且有TLS保護，用于遠端連接配接(如：通過kubectl管理叢集)。
官方文檔對兩種API的描述如下：
随着K8s在雲上的普及，針對8080端口的公網未授權通路利用數年間從未停止，雲服務商提供的容器預設已不存在該問題，但使用者基于伺服器自建K8s叢集如仍存在少量開放到公網并被蠕蟲入侵的案例。
6443端口的利用要通過API Server的鑒權，直接通路會提示匿名使用者鑒權失敗：
這為自動化攻擊提供了便利，黑客通過批量掃描開放在公網的6443端口，向存在鑒權問題的叢集下發挖礦程式。在2019年我們監控到首次大規模針對6443端口的利用，如今針對6443鑒權問題的K8s蠕蟲卷土重來，并帶來了更為複雜、隐蔽的利用方式。
安全建議1- 自查
K8s API Server 6443鑒權問題需要關注，可以通過以下指令自查"system:anonymous"擁有的權限：
kubectl get clusterrolebindings -o yaml | grep system:anonymous
安全建議2- 規範化使用RBAC
正确使用RBAC政策綁定，不要改變或新增叢集原生使用者或組（system:開頭）的權限綁定，也不要改變系統原生的叢集角色(clusterrole)或角色(role)。
阿裡雲容器服務在控制台提供了可視化的授權管理頁面，根據不同的應用場景提供了對應的預置叢集角色模闆，友善使用者對指定子賬号或RAM角色進行叢集或namespace次元的權限綁定，同時支援使用者自定義叢集權限的控制台綁定，減少使用者對RBAC的學習成本。詳情參見：
https://help.aliyun.com/document_detail/119596.html?spm=a2c4g.11186623.6.627.385a2b303VW0sP安全建議3- 謹慎開啟叢集公網
盡量使用内網方式建立叢集，減少apiserver暴露在公網上受到攻擊的可能性。
安全建議4- K8s日志審計
K8s日志的安全審計除了攻擊特征/威脅情報的黑名單比對之外，還需對通路者建立行為鍊路的審計以覆寫匿名通路或憑證洩露後鑒權成功的攻擊事件。
安全建議5-使用阿裡雲容器服務預設配置并開啟威脅檢測功能
阿裡雲容器服務預設不受此攻擊影響，建議采用預設鑒權配置，并通過以下配置開啟雲安全中心K8s威脅檢測功能，第一時間發現通過K8s API Server發起的入侵事件。
安全建議6- 使用PSP安全政策
PodSecurityPolicy（簡稱PSP）是Kubernetes中Pod部署時重要的安全校驗手段，能夠有效地限制應用運作時行為安全。當一個攻擊者已經擷取到叢集的通路憑證時，有效的PSP政策配置和綁定可以通過阻止攻擊者部署特權容器或挂載敏感目錄等校驗手段，有效阻止攻擊者進行下一步入侵，詳情參見：
https://help.aliyun.com/document_detail/173620.html?spm=a2c4g.11186623.6.845.596116d7A2vLE6安全建議7- 安全管理kubeconfig憑證
對于ACK容器服務标準版叢集來說，kubeconfig是使用者通路叢集apiserver的唯一憑證，要嚴格控制擁有管理者權限的kubeconfig憑證的發放範圍，對于可能洩露的憑證要及時吊銷，吊銷方法請參見:
https://help.aliyun.com/document_detail/142602.html?spm=a2c4g.11186623.6.839.16d37f4bxIbUku