具體來說，惡意用戶可以使用 KubernetesAPI 服務(wù)器連接到后端服務(wù)器以發(fā)送任意請(qǐng)求，并通過 API 服務(wù)器的 TLS 憑證進(jìn)行身份驗(yàn)證。這一安全漏洞的嚴(yán)重性更在于它可以遠(yuǎn)程執(zhí)行，攻擊并不復(fù)雜，不需要用戶交互或特殊權(quán)限。

更糟糕的是，在 Kubernetes 的默認(rèn)配置中，允許所有用戶（經(jīng)過身份驗(yàn)證和未經(jīng)身份驗(yàn)證的用戶）執(zhí)行允許此升級(jí)的發(fā)現(xiàn) API 調(diào)用。也就是說，任何了解這個(gè)漏洞的人都可以掌控你的 Kubernetes 集群。

最后的痛苦之處在于，對(duì)于用戶而言，沒有簡(jiǎn)單的方法來檢測(cè)此漏洞是否已被使用。由于未經(jīng)授權(quán)的請(qǐng)求是通過已建立的連接進(jìn)行的，因此它們不會(huì)出現(xiàn)在 Kubernetes API 服務(wù)器審核日志或服務(wù)器日志中。請(qǐng)求確實(shí)會(huì)出現(xiàn)在 kubelet 或聚合的API服務(wù)器日志中，但是卻無法與正確通過 Kubernetes API 服務(wù)器授權(quán)和代理的請(qǐng)求區(qū)分開來。

現(xiàn)在，Kubernetes 已經(jīng)發(fā)布了修補(bǔ)版本 v1.10.11、v1.11.5、v1.12.3 和 v1.13.0-rc.1。如果仍在使用 Kubernetes v1.0.x 至 Kubernetes v1.9.x 版本，請(qǐng)即刻停止使用并升級(jí)到修補(bǔ)版本。

如果由于某種原因無法進(jìn)行升級(jí)，也必須暫停使用聚合的 API 服務(wù)器，并從不應(yīng)具有對(duì) kubelet API 的完全訪問權(quán)限的用戶中刪除 pod exec/attach/portforward 權(quán)限。

Kubernetes作為一個(gè)分布式集群的管理工具，保證集群的安全性是其一個(gè)重要的任務(wù)。API Server是集群內(nèi)部各個(gè)組件通信的中介，也是外部控制的入口。所以Kubernetes的安全機(jī)制基本就是圍繞保護(hù)API Server來設(shè)計(jì)的。

Kubernetes使用了認(rèn)證（Authentication）、鑒權(quán)（Authorization）、準(zhǔn)入控制（Admission Control）三步來保證API Server的安全。

Kubelet 認(rèn)證

默認(rèn)情況下，所有未被配置的其他身份驗(yàn)證?法拒絕的，對(duì)kubelet的HTTPS端點(diǎn)的請(qǐng)求將

被視為匿名請(qǐng)求，并被授予system:anonymous?戶名和system:unauthenticated組。

如果要禁?匿名訪問并發(fā)送 401 Unauthorized 的未經(jīng)身份驗(yàn)證的請(qǐng)求的響應(yīng)：

啟動(dòng)kubelet時(shí)指定 --anonymous-auth=false

對(duì)kubelet HTTPS端點(diǎn)啟?X509客戶端證書身份驗(yàn)證：

--client-ca-file 提供 CA bundle 以驗(yàn)證客戶端證書

啟動(dòng)apiserver時(shí)指定--kubelet-client-certificate和--kubelet-client-key標(biāo)志

Secret

Kubernetes設(shè)計(jì)了?種資源對(duì)象叫做Secret，分為兩類，?種是?于ServiceAccount的

service-account-token

另?種是?于保存?戶?定義保密信息的Opaque。我們?cè)赟erviceAccount中?到包含三個(gè)

部分：Token、ca.crt、namespace。

token 是使?API Server私鑰簽名的JWT。?于訪問API Server時(shí)，Server端認(rèn)證。

ca.crt ，根證書。?于Client端驗(yàn)證API Server發(fā)送的證書。

namespace , 標(biāo)識(shí)這個(gè)service-account-token的作?域名空間。

更詳細(xì)參考：https://k8smeetup.github.io/docs/admin/kubelet-authenticationauthorization/

通過kubelet攻擊Kubernetes

通過kubelet默認(rèn)配置對(duì)Kubernetes集群上的API Server發(fā)起特權(quán)訪，特權(quán)訪問有可能會(huì)獲取集群中的敏感信息，也可能導(dǎo)致節(jié)點(diǎn)上機(jī)器命令執(zhí)?。

API Server提供了對(duì)集群各種資源訪問和控制的REST API。

在缺少對(duì)TLS身份驗(yàn)證，?在?些默認(rèn)配置中啟?了，--anonymous-auth 默認(rèn)為true

允許匿名身份訪問API,端?為10250

/pods # 列出正在運(yùn)?中的pod

/exec # 在容器中運(yùn)?命令并反回信息

這?我從shodan上隨意找的IP進(jìn)?測(cè)試

https://192.168.4.110:10250/pods

獲取信息執(zhí)?容器中的命令：

CURL請(qǐng)求：

不過有點(diǎn)可惜，較?版本現(xiàn)在已經(jīng)?不通了。

除了通過curl請(qǐng)求，提供了這樣的?個(gè)腳本執(zhí)?Kubelet Anonymous RCE :

https://github.com/serain/kubelet-anon-rce

幫助?檔例?：

如果能執(zhí)?命令可以通過:

/var/run/secrets/kubernetes.io/serviceaccount 獲取token

然后訪問kube-api server

測(cè)試步驟：

1. 訪問pods獲取信息

2. 獲取namespace、pods、container

3. 執(zhí)?exec獲取token

4. /var/run/secrets/kubernetes.io/serviceaccount

5. 利?Token訪問API Server進(jìn)?對(duì)pods操作

Kube-Hunter尋找漏洞

使?Kube-hunter尋找Kubernetes集群中的安全漏洞。

會(huì)對(duì)apiserver、dashboard、etcd、hosts、kubelet、ports、proxy進(jìn)?測(cè)試。

https://github.com/aquasecurity/kube-hunter

通過?些信息判斷，發(fā)現(xiàn)匿名身份驗(yàn)證，可以訪問pods 查看信息。

對(duì)外?IP掃描：

Kubelet API | 91.xxx.xxx.x2:10255

Kubelet API | 91.xxx.xxx.x2:10250

API Server | 91.xxx.xxx.x2:6443