淺談雲安全之K8S
k8s是什麼?
Kubernetes 是一個可移植的，可擴展的開源容器編排平臺，用於管理容器化的工作負載和服務，方便了聲明式配置和自動化。它擁有一個龐大且快速增長的生態系統。Kubernetes 的服務，支持和工具廣泛可用。
爲什麼現在流行使用容器?
早期: 在物理服務器上面部署應用程序存在資源分配問題,因爲其不能在物理服務器中的應用程序定義資源邊界,導致應用程序資源利用不足而無法擴展.
後來: 爲了解決該問題,引入了虛擬化技術, 虛擬化技術是指允許你在單個物理服務器的 CPU 上運行多個虛擬機,可以讓多個應用程序在虛擬機之間進行隔離,具有一定的安全性, 每一個虛擬機就是一臺完整的計算機, 在虛擬化硬件之上運行所有組件.
現在: 多數在物理服務器上面部署應用程序都是採kubectl用容器的方式,容器類似於虛擬機,它們都具有自己的文件系統、CPU、內存、進程空間等, 且由於它們與基礎架構分離，因此可以跨雲和 OS 發行版本進行移植。基於此特點被企業大範圍使用.
爲什麼需要使用k8s容器?
若出現這樣一個環境: 在生產環境中如果一個容器發生故障,則我們需要手動去啓動另外一個容器,這樣的操作是對我們的管理員來說是不太方便的, 若一個容器出現故障,另一個容器可以自動啓動容器接管故障的容器,這樣是最好的.
k8s就可以實現該效果,Kubernetes 提供了一個可彈性運行分佈式系統的框架。 Kubernetes 會滿足你的擴展要求、故障轉移、部署模式等。
k8s功能: 服務發現和負載均衡, 存儲編排, 自動部署和回滾, 自動完成裝箱計算, 自我修復, 密鑰與配置管理
名詞解釋
secret
Secret有三種類型：
k8s的組成
k8s是由組件,API,對象等組成.
包含所有相互關聯組件的 Kubernetes 集羣圖如下:
組件
API
Kubernetes 控制面 的核心是 API 服務器。 API 服務器負責提供 HTTP API，以供用戶、集羣中的不同部分和集羣外部組件相互通信。
對象
Kubernetes對象是Kubernetes系統中的持久實體。Kubernetes使用這些實體來表示集羣的狀態.
具體來說，他們可以描述：
Kubernetes 架構
Kubernetes 架構由節點,控制面到節點通信, 控制器, 雲控制器管理器組成.
master 流程圖
節點
節點可以是一個虛擬機或者物理機器，取決於所在的集羣配置。 每個節點包含運行 Pods 所需的服務， 這些 Pods 由 控制面 負責管理.
節點上的組件包括 kubelet、 容器運行時以及 kube-proxy。
節點狀態
可以使用 kubectl 來查看節點狀態和其他細節信息：
kubectl describe node <�節點名稱>
一個節點包含以下信息:
控制面到節點通信
控制器
在 Kubernetes 中，控制器通過監控集羣 的公共狀態，並致力於將當前狀態轉變爲期望的狀態。
舉個例子: 當前室內溫度爲20度, 我們通過調節遙控器,使其溫度上升至24度, 這20度到24度的變化即爲讓其從當前狀態接近期望狀態。
控制器模式分爲直接控制和通過API服務器來控制.
雲控制器管理器
雲控制器管理器是指嵌入特定雲的控制邏輯的 控制平面組件。 雲控制器管理器允許您鏈接聚合到雲提供商的應用編程接口中， 並分離出相互作用的組件與您的集羣交互的組件。
雲控制器管理器中的控制器包括：
Kubernetes 安全性
雲原生安全
雲原生安全4個C: 雲(Cloud)、集羣(Cluster)、容器(Container)和代碼(Code)
雲原生安全模型的每一層都是基於下一個最外層，代碼層受益於強大的基礎安全層（雲、集羣、容器）。我們無法通過在代碼層解決安全問題來爲基礎層中糟糕的安全標準提供保護。
基礎設施安全
Kubetnetes 基礎架構關注領域
建議
通過網絡訪問 API 服務（控制平面)
所有對 Kubernetes 控制平面的訪問不允許在 Internet 上公開，同時應由網絡訪問控制列表控制，該列表包含管理集羣所需的 IP 地址集。
通過網絡訪問 Node（節點)
節點應配置爲 僅能 從控制平面上通過指定端口來接受（通過網絡訪問控制列表）連接，以及接受 NodePort 和 LoadBalancer 類型的 Kubernetes 服務連接。如果可能的話，這些節點不應完全暴露在公共互聯網上。
Kubernetes 雲訪問提供商的 API
每個雲提供商都需要向 Kubernetes 控制平面和節點授予不同的權限集。爲集羣提供雲提供商訪問權限時，最好遵循對需要管理的資源的最小特權原則。Kops 文檔提供有關 IAM 策略和角色的信息。
訪問 etcd
對 etcd（Kubernetes 的數據存儲）的訪問應僅限於控制平面。根據配置情況，你應該嘗試通過 TLS 來使用 etcd。更多信息可以在 etcd 文檔中找到。
etcd 加密
在所有可能的情況下，最好對所有驅動器進行靜態數據加密，但是由於 etcd 擁有整個集羣的狀態（包括機密信息），因此其磁盤更應該進行靜態數據加密。
集羣組件安全
容器安全
代碼安全
Kubernetes架構常見問題
Kubernetes ATTACK 矩陣
信息泄露
雲賬號AK泄露
API憑證（即阿里雲AccessKey）是用戶訪問內部資源最重要的身份憑證。用戶調用API時的通信加密和身份認證會使用API憑證.
API憑證是雲上用戶調用雲服務API、訪問雲上資源的唯一身份憑證。
API憑證相當於登錄密碼，用於程序方式調用雲服務API.
k8s configfile泄露
kubeconfig文件所在的位置:
$HOME/.kube/config
Kubeconfig文件包含有關Kubernetes集羣的詳細信息，包括它們的位置和憑據。
雲廠商會給用戶提供該文件,以便於用戶可以通過kubectl對集羣進行管理. 如果攻擊者能夠訪問到此文件（如辦公網員工機器入侵、泄露到Github的代碼等），就可以直接通過API Server接管K8s集羣，帶來風險隱患。
Master節點SSH登錄泄露
常見的容器集羣管理方式是通過登錄Master節點或運維跳板機，然後再通過kubectl命令工具來控制k8s。
雲服務器提供了通過ssh登陸的形式進行登陸master節點.
若Master節點SSH連接地址泄露,攻擊者可對ssh登陸進行爆破,從而登陸上ssh,控制集羣.
容器組件未鑑權服務
Kubernetes架構下常見的開放服務指紋如下:
注:前六個重點關注: 一旦被控制可以直接獲取相應容器、相應節點、集羣權限的服務
瞭解各個組件被攻擊時所造成的影響
組件分工圖:
假如用戶想在集羣裡面新建一個容器集合單元, 流程如下:
攻擊apiserver
apiserver介紹:在Kubernetes中,對於未鑑權對apiserver, 能訪問到 apiserver 一般情況下就能獲取了集羣的權限.
在攻擊者眼中Kubernetes APIServer
默認情況下apiserver都有鑑權:
未鑑權配置如下:
對於這類的未鑑權的設置來說，訪問到 apiserver 一般情況下就獲取了集羣的權限：
如何通過apiserver來進行滲透,可參考:https://Kubernetes.io/docs/reference/generated/kubectl/kubectl-commands
攻擊kubelet
每一個Node節點都有一個kubelet(每個節點上運行的代理)服務，kubelet監聽了10250，10248，10255等端口。
10250端口,是kubelet與apiserver進行通信對主要端口, 通過該端口,kubelet可以知道當前應該處理的任務.該端口在最新版Kubernetes是有鑑權的, 但在開啓了接受匿名請求的情況下，不帶鑑權信息的請求也可以使用10250提供的能力, 在Kubernetes早期,很多挖礦木馬基於該端口進行傳播.
在配置文件中,若進行如下配置,則可能存在未授權訪問漏洞.
/var/bin/kubulet/config/yaml
若10250端口存在未授權訪問漏洞,我們可以直接訪問/pods進行查看
根據在pods中獲取的信息,我們可以在容器中執行命令
curl -Gks https://host:10250/exec/{namespace}/{podname}/{containername} \-d 'input=1' -d 'output=1' -d 'tty=1' \-d 'command=whoami'
上述命令得到websocket地址，連接websocket得到命令結果：
使用wscat工具連接websocket
wscat -c “https://X.X.X.X:10250/{websocket}” --no-check
即可得到我們執行命令的結果.
獲取token
/var/run/secrets/kubernetes.io/serviceaccount
然後即可訪問kube-api server,獲取集羣權限
curl -ks -H "Authorization: Bearer \ ttps://master:6443/api/v1/namespaces/{namespace}/secrets
"
攻擊kubelet總體步驟如下:
攻擊dashboard
dashboard登陸鏈接如下:
http://xxx.xxx.xxx.xxx:xxxx/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/#/login
dashboard界面如下:
dashboard是Kubernetes官方推出的控制Kubernetes的圖形化界面.在Kubernetes配置不當導致dashboard未授權訪問漏洞的情況下，通過dashboard我們可以控制整個集羣。
默認情況下, dashboard是需要進行鑑權操作的,當用戶開啓了enable-skip-login時可以在登錄界面點擊Skip跳過登錄進入dashboard.
通過skip登陸的dashboard默認是沒有操作集羣的權限,因爲Kubernetes使用RBAC(Role-based access control)機制進行身份認證和權限管理，不同的serviceaccount擁有不同的集羣權限。
但有些開發者爲了方便或者在測試環境中會爲Kubernetes-dashboard綁定cluster-admin這個ClusterRole（cluster-admin擁有管理集羣的最高權限）.
爲Kubernetes-dashboard綁定cluster-admin 設置如下:
後通過skip登陸dashboard便有了管理集羣的權限.
創建Pod控制node節點,該pod主要是將宿主機根目錄掛載到容器tmp目錄下。
新建一個Pod如下:
通過該容器的tmp目錄管理node節點的文件
攻擊etcd
Kubernetes默認使用了etcd v3來存儲數據, 若能naetcd對內暴露2379端口，本地127.0.0.1可免認證訪問. 其他地址要帶—endpoint參數和cert進行認證。
未授權訪問流程:
攻擊docker remote api(Docker daemon公網暴露)
2375是docker遠程操控的默認端口，通過這個端口可以直接對遠程的docker 守護進程進行操作。Docker 守護進程默認監聽2375端口且未鑑權.
當機器以方式啓動daemon時，可以在外部機器對該機器的docker daemon進行直接操作：
docker daemon -H=0.0.0.0:2375
之後依次執行systemctl daemon-reload、systemctl restart docker
外部主機使用 即可操作暴露2375端口的主機.
-H
因此當你有訪問到目標Docker API 的網絡能力或主機能力的時候，你就擁有了控制當前服務器的能力。我們可以利用Docker API在遠程主機上創建一個特權容器，並且掛載主機根目錄到容器.
檢測目標是否存在docker api未授權訪問漏洞的方式也很簡單，訪問http://[host]:[port]/info路徑是否含有ContainersRunning、DockerRootDir等關鍵字。
攻擊kubectl proxy
二次開發所產生的問題
管理Kubernetes無論是使用 kubectl 或 Kubernetes dashboard 的UI功能，其實都是間接在和 APIServer 做交互.
如果有需求對k8s進行二次開發的話,大部分的開發功能請求了 APIServer 的 Rest API 從而使功能實現的。
例如:
類似於這樣去調用apiserver, 攻擊者若修改namespace、pod和容器名, 那麼即可造成越權.
推薦工具
Kube-Hunter掃描漏洞
kube-hunter是一款用於尋找Kubernetes集羣中的安全漏洞掃描器
下載地址: https://github.com/aquasecurity/kube-hunter
CDK(強推)
CDK是一款爲容器環境定製的滲透測試工具，在已攻陷的容器內部提供零依賴的常用命令及PoC/EXP。集成Docker/K8s場景特有的 逃逸、橫向移動、持久化利用方式，插件化管理。
下載地址: https://github.com/cdk-team/CDK/wiki/CDK-Home-CN
參考鏈接
https://developer.aliyun.com/article/765449?groupCode=aliyunsecurityhttps://xz.aliyun.com/t/4276#toc-2https://www.secrss.com/articles/29544https://kubernetes.io/zh/docs/concepts/workloads/pods/#what-is-a-podhttps://www.huweihuang.com/kubernetes-notes/concepts/architecture/kubernetes-architecture.htmlhttps://www.kubernetes.org.cn/service-accounthttps://www.aquasec.com/cloud-native-academy/cloud-native-applications/cloud-native-infrastructure/https://www.cdxy.me/?p=827