揚(yáng)州外貿(mào)網(wǎng)站seo正規(guī)的培訓(xùn)機(jī)構(gòu)有哪些
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ū)討論!