Kubernetes（K8S）因其強(qiáng)大的容器編排能力成為了云計(jì)算和微服務(wù)架構(gòu)的首選，但同時(shí)也帶來了復(fù)雜的安全挑戰(zhàn)。本文將概述K8S的主要安全問題，幫助安全工程師理解潛在威脅，并采取相應(yīng)的防護(hù)措施。?

K8S 攻擊面概覽

下面兩張圖總結(jié)了 K8S 集群架構(gòu)中可能存在的安全問題，并在第一張K8S 集群基礎(chǔ)架構(gòu)圖中直觀標(biāo)出了潛在的攻擊點(diǎn)。

下面是K8S組件存在隱患的默認(rèn)端口：

組件名稱	默認(rèn)端口
api server	8080/6443
dashboard	8001/30000+/自定義
kubelet	10250/10255
etcd	2379
kube-proxy	8001
docker	2375
kube-scheduler	10251
kube-controller-manager	10252

Kubernetes (K8s) 的安全問題主要來源于不安全的配置，尤其是未授權(quán)訪問，另外就是配置的泄露。K8s 作為一個(gè)復(fù)雜的容器編排系統(tǒng)，涉及多個(gè)組件和配置文件，如果沒有良好的安全控制和嚴(yán)格的配置管理，可能會(huì)引發(fā)各種安全風(fēng)險(xiǎn)。

---

一、API Server 未授權(quán)訪問

API Server 是 Kubernetes 集群的核心管理接口，所有資源請求和操作都通過 kube-apiserver 提供的 API 進(jìn)行處理。默認(rèn)情況下，API Server 會(huì)監(jiān)聽兩個(gè)端口：8080 和 6443。如果配置不當(dāng)，可能會(huì)導(dǎo)致未授權(quán)訪問的安全風(fēng)險(xiǎn)。

8080 端口默認(rèn)情況下不啟用，該端口不需要認(rèn)證和授權(quán)檢查。如果意外暴露（v1.20以下版本），攻擊者可以直接訪問集群資源，導(dǎo)致未授權(quán)訪問。--insecure-port 和 --insecure-bind-address 參數(shù)已經(jīng)被 廢棄，在 Kubernetes v1.20+ 版本中它們已經(jīng)無法正常使用，尤其是 --insecure-port，只能被設(shè)置為 0，否則會(huì)導(dǎo)致 API Server 啟動(dòng)失敗。

6443 端口默認(rèn)啟用，并且要求認(rèn)證。如果配置錯(cuò)誤，例如將 `system:anonymous` 用戶綁定到 `cluster-admin` 用戶組，攻擊者可能繞過認(rèn)證，獲得集群管理員權(quán)限，造成未授權(quán)訪問。

具體分析文章：【云安全】云原生- K8S API Server 未授權(quán)訪問-CSDN博客

---

二、Kubectl Proxy 不安全配置

kubectl proxy 的作用是將 Kubernetes API Server 暴露給本地網(wǎng)絡(luò)或客戶端，允許你通過本地代理與 Kubernetes 集群進(jìn)行交互。具體來說，kubectl proxy 可以暴露以下內(nèi)容：

1、Kubernetes API Server

暴露的內(nèi)容：kubectl proxy 允許你通過代理訪問 Kubernetes API Server，進(jìn)行集群管理和操作。這包括訪問集群資源（如 Pods、Services、Deployments、ConfigMaps 等），執(zhí)行命令（例如 kubectl get、kubectl apply）。

風(fēng)險(xiǎn)：如果沒有配置適當(dāng)?shù)恼J(rèn)證和授權(quán)，任何可以訪問代理端口的用戶都可以通過它進(jìn)行操作，甚至執(zhí)行惡意行為。即導(dǎo)致了“API Server未授權(quán)訪問”

漏洞復(fù)現(xiàn)：

kubectl proxy --port=8080 --address=0.0.0.0 --accept-hosts='.*' &#驗(yàn)證，查看進(jìn)程
ps aux | grep kubectl | grep -v grep#關(guān)閉
kill <PID>

典型的API Server未授權(quán)訪問頁面，具體分析見上文“API Server 未授權(quán)訪問”

2、Kubernetes Dashboard

暴露的內(nèi)容：如果你在集群中部署了 Kubernetes Dashboard，kubectl proxy 可以暴露該 Dashboard 的 Web 界面，使你能夠通過瀏覽器訪問 Dashboard。默認(rèn)情況下，Dashboard 可以在 http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/ 訪問。

風(fēng)險(xiǎn)：如果沒有啟用適當(dāng)?shù)恼J(rèn)證（如 OIDC 或 RBAC），攻擊者可能利用代理訪問 Dashboard，并進(jìn)行未授權(quán)的操作。具體分析見下文“Dashboard未授權(quán)訪問”！

3、集群內(nèi)的其他服務(wù)

暴露的內(nèi)容：kubectl proxy 還可以訪問集群中暴露的其他服務(wù)和端點(diǎn)。例如，通過代理，你可以訪問 Kubernetes 集群中的某些 HTTP 服務(wù)，尤其是那些已通過 Kubernetes Service 暴露的服務(wù)。

風(fēng)險(xiǎn)：如果某些服務(wù)沒有進(jìn)行適當(dāng)?shù)纳矸蒡?yàn)證或授權(quán)控制，攻擊者可能利用 kubectl proxy 訪問這些服務(wù)，并執(zhí)行惡意操作。

4、API 擴(kuò)展端點(diǎn)

暴露的內(nèi)容：Kubernetes 支持 API 擴(kuò)展，如自定義資源定義（CRDs）。kubectl proxy 允許你訪問和管理這些擴(kuò)展 API 端點(diǎn)。

風(fēng)險(xiǎn)：如果這些自定義資源沒有嚴(yán)格的訪問控制，攻擊者可以通過 kubectl proxy 修改或刪除重要資源。

---

三、etcd 未授權(quán)訪問

在 Kubernetes (K8s) 中，etcd 是一個(gè)關(guān)鍵的分布式鍵值存儲(chǔ)系統(tǒng)，它存儲(chǔ)了集群的所有配置信息和狀態(tài)數(shù)據(jù)。由于它存儲(chǔ)著 K8s 集群的核心數(shù)據(jù)，因此保護(hù) etcd 是非常重要的。以下是 etcd 未授權(quán)訪問產(chǎn)生的原因：

1、未加密的數(shù)據(jù)傳輸：

默認(rèn)情況下，etcd 可能會(huì)在集群中使用未加密的 HTTP 通信協(xié)議。沒有加密的傳輸可能導(dǎo)致中間人攻擊（MITM），攻擊者可能會(huì)截獲、篡改或偽造請求，進(jìn)而導(dǎo)致敏感數(shù)據(jù)泄露。

2、未加密的數(shù)據(jù)存儲(chǔ)：

如果 etcd 的數(shù)據(jù)存儲(chǔ)未加密，存儲(chǔ)在磁盤上的敏感數(shù)據(jù)（如 API 密鑰、身份驗(yàn)證憑證等）可能會(huì)被未經(jīng)授權(quán)的用戶訪問。如果攻擊者能夠訪問存儲(chǔ)卷，他們可能會(huì)竊取這些數(shù)據(jù)。

3、缺乏認(rèn)證和授權(quán)：

如果 etcd 沒有啟用身份驗(yàn)證和授權(quán)機(jī)制，任何能夠訪問 etcd 實(shí)例的用戶或進(jìn)程都可以讀寫數(shù)據(jù)。缺乏訪問控制會(huì)導(dǎo)致潛在的安全漏洞，攻擊者可以篡改配置或獲取敏感數(shù)據(jù)。

4、不安全的集群通信：

如果 etcd 集群之間的通信沒有加密或者沒有正確配置 TLS，集群成員之間的通信可能會(huì)受到攻擊。攻擊者可以偽造數(shù)據(jù)或與集群進(jìn)行惡意交互。

5、未經(jīng)審計(jì)的訪問：

如果沒有啟用審計(jì)日志，etcd 可能無法記錄所有對數(shù)據(jù)的訪問和修改。缺乏審計(jì)日志使得追蹤惡意行為變得困難，增加了診斷和響應(yīng)的復(fù)雜性。

6、Etcd 服務(wù)的暴露：

如果 etcd 服務(wù)被公開在互聯(lián)網(wǎng)上且沒有妥善保護(hù)（如防火墻規(guī)則、網(wǎng)絡(luò)隔離、身份驗(yàn)證等），攻擊者可以直接訪問 etcd，造成安全風(fēng)險(xiǎn)。

具體分析文章：【云安全】云原生- K8S etcd 未授權(quán)訪問-CSDN博客

---

四、Kubelet 未授權(quán)訪問

Kubelet未授權(quán)訪問通常指的是未經(jīng)過身份驗(yàn)證的用戶或服務(wù)能夠直接訪問Kubelet的API，可能導(dǎo)致集群安全風(fēng)險(xiǎn)。Kubelet負(fù)責(zé)管理每個(gè)節(jié)點(diǎn)上的Pod和容器，若未授權(quán)訪問未被妥善管控，攻擊者可以利用此漏洞獲取敏感信息或控制容器。

該問題主要是由 /var/lib/kubelet/config.yaml 以下不安全配置引起

10250端口：默認(rèn)開啟端口，但是需要授權(quán)

10255端口：只讀端口，默認(rèn)不開放，需要進(jìn)行配置

具體分析文章：【云安全】云原生- K8S Kubelet 未授權(quán)訪問-CSDN博客

---

五、kubeconfig文件泄露

kubeconfig 文件是 Kubernetes 的配置文件，kubectl 使用它來連接和與 Kubernetes 集群交互。它通常位于 ~/.kube/config 路徑下，包含多個(gè)上下文、集群、用戶的配置信息，用于定義 kubectl 如何與不同的集群進(jìn)行通信。?

kubeconfig 文件如果泄露，可能會(huì)導(dǎo)致攻擊者獲得對 Kubernetes 集群的訪問權(quán)限。常見的泄露途徑包括：將其上傳至版本控制系統(tǒng)（如 GitHub）時(shí)未忽略該文件，存儲(chǔ)在不安全的目錄中，或通過不當(dāng)?shù)臋?quán)限管理使得文件可被其他用戶讀取。攻擊者可以通過 Webshell、GitHub 等方式獲取到此文件，從而通過 API Server 接管整個(gè) Kubernetes 集群，控制所有容器。kubeconfig 文件作為集群的管理憑證，包含關(guān)于集群的詳細(xì)信息，如 API Server 地址、認(rèn)證憑證等。如果攻擊者能夠訪問到該文件（如辦公網(wǎng)員工機(jī)器被入侵或文件泄露到 GitHub），他們可以直接通過 API Server 獲得集群的控制權(quán)限，導(dǎo)致嚴(yán)重的安全風(fēng)險(xiǎn)和隱患。

具體分析文章：【云安全】云原生- K8S kubeconfig 文件泄露-CSDN博客

---

六、Dashboard未授權(quán)訪問

面板安裝教程：【云安全】云原生-K8S（三） 安裝 Dashboard 面板-CSDN博客?

漏洞復(fù)現(xiàn)

通過以下命令編輯deployment

kubectl -n kubernetes-dashboard edit deployment kubernetes-dashboard

將以下配置添加到args字段中

- --enable-skip-login

這樣就可以在登錄界面點(diǎn)擊跳過登錄進(jìn)dashboard?

將默認(rèn)的Kubernetes-dashboard綁定cluster-admin，擁有管理集群管權(quán)限?

kubectl create clusterrolebinding dashboard-1 --clusterrole=cluster-admin --serviceaccount=kubernetes-dashboard:kubernetes-dashboard

訪問Kubernetes 儀表盤，出現(xiàn)了跳過按鈕，點(diǎn)擊跳過進(jìn)入dashboard

創(chuàng)建惡意POD

---

總結(jié)

K8S提供了強(qiáng)大的容器編排能力，但同時(shí)也帶來了諸多安全風(fēng)險(xiǎn)，尤其是未授權(quán)訪問風(fēng)險(xiǎn)。至于其他web安全通用問題（如XSS、SQL注入等）和容器特有的安全問題（如鏡像漏洞、容器隔離性問題等），雖然對K8s來說也是需要關(guān)注的，但從K8s本身的架構(gòu)和配置角度來說，確實(shí)更多的是與配置相關(guān)的安全問題。如果你有任何關(guān)于K8S安全的疑問或想深入了解具體攻擊手法，歡迎在評論區(qū)討論！