从Pod到集群管理员：一次完整的K8s渗透测试工具链实战解析
最近在做一次授权的K8s渗透测试，目标是一个生产环境中的私有集群。整个测试走完一遍之后，我最大的感触是：K8s环境下，拿到一个Pod的身份往往只是开始，要完成从Pod到集群管理员的跃迁，考验的不仅是单个漏洞的利用能力，更是整条工具链的串联能力。这篇文章不是从教科书出发讲K8s安全，而是把我实际测试中用的那套工具链、踩过的坑、换过的思路完整梳理出来，希望能给正在做云原生安全测试或者运维转安全的朋友一点参考。
先说明一点：本文所有内容均基于授权测试场景，所有命令和工具都用于验证自有或授权目标的安全性。安全测试的核心边界是授权，没有授权的“扫描”就是攻击，这个底线不能破。读完这篇文章，你会清楚理解一条完整的攻击链——从应用漏洞进入Pod，再到通过kubelet API拿下Node，最后利用控制面配置缺陷拿到集群管理员权限——以及每个环节里工具选择的逻辑和操作细节。
1. K8s渗透测试的核心目标与攻防范式
1.1 为什么K8s集群成了渗透测试的必争之地
传统渗透测试中，我们的攻击目标通常是IP、域名、服务器和Web应用。但到了云原生阶段，业务形态发生了根本变化：一个跑在K8s上的生产集群，可能同时承载了支付系统、用户中心、数据处理、CI/CD流水线等几十套业务。过去的网络边界防护、主机加固、Web防火墙都还在，但K8s抽象出了一层全新的攻击面——Pod、Service、Namespace、RBAC、Secret、etcd、kubelet，任何一个配置失误都可能变成突破口。
从攻击者视角看，K8s集群的吸引力在于“一次突破，全盘皆输”。如果拿到了cluster-admin权限，意味着整个集群的Deployment、ConfigMap、Secret、Node上的所有容器都暴露在眼前。很多团队在K8s安全上有一个误区：认为容器隔离等同于安全隔离，实际上Pod内默认挂载的ServiceAccount token、宿主机的共享内核、kubelet的匿名端口，任何一项都可能击穿这个假设。
1.2 与传统主机渗透的差异：三层权限模型
传统渗透测试的权限模型基本是“服务器用户权限→root权限”两层。K8s引入了一个三层权限模型：Pod权限、Node权限、Cluster权限。从Pod到Node，再从Node到Cluster，每一层都有不同的认证和授权机制，这决定了工具链的设计思路完全不同。
你在一台Linux服务器上拿到www用户Shell，接下来大概率就是提权、翻配置文件、找数据库凭据。但你在K8s里拿到一个Pod Shell，此时你拥有的是这个Pod绑定的ServiceAccount（SA）权限，而不是节点权限，更不是集群权限。K8s访问控制的核心是RBAC，每个SA能做什么，由Role、ClusterRole、RoleBinding、ClusterRoleBinding决定。这也就是为什么K8s渗透测试工具链里，kubectl、curl配合jq这么重要——你首先得弄清楚“我是谁、我能做什么”，然后才有下一步动作。
2. 工具链整体设计：五个阶段环环相扣
2.1 从信息收集到权限维持的完整链路
根据我多次实战的复盘，K8s渗透测试工具链通常可以拆成五个阶段：信息收集、漏洞探测、攻击利用、横向移动、权限维持与痕迹清理。这五个阶段不是割裂的，前一个阶段的输出直接决定后一个阶段用什么工具。
信息收集阶段，目标是用最快速度摸清集群的版本、Namespace、Service、Pod、RBAC角色和网络策略。这个阶段kubectl加jq就是主力，配合curl手工请求API Server效果更好。漏洞探测阶段，kube-hunter这类扫描器可以快速检查已知的K8s配置缺陷，但不要把全部希望寄托在扫描器上，很多环境里的问题扫描器发现不了，比如kubelet 10250端口匿名访问、etcd未授权绑定、Pod里可以直接访问云metadata服务等，这些都需要手工确认。攻击利用阶段，cdk和kubeletctl在处理容器逃逸、kubelet API利用上效率很高。横向移动阶段，拿到Node权限后，重点变成翻找控制面配置和证书。权限维持阶段，一般推荐不要做过于持久的后门，重点放在获取高权限凭据并保留访问方式上。
2.2 工具选型逻辑与核心工具清单
我在K8s安全测试中坚持一个原则：工具链不等于工具全家桶，能少装就少装。原因是目标集群的环境高度异构，网络策略、RBAC、容器运行时都不同，盲目依赖重型工具链反而容易暴露身份或踩坏生产环境。下面这张表是我在实际测试中最常用的工具清单，并标注了每个工具在链路中的定位。
| 阶段 | 工具 | 核心用途 | 使用要点 |
|---|---|---|---|
| 信息收集 | kubectl + jq | 查询集群资源，分析RBAC权限 | 在Pod内使用SA token时无需配置kubeconfig |
| 信息收集 | curl + openssl | 手工调用API Server，分析证书和Token | 适合绕过kubectl默认行为，直接看HTTP状态码 |
| 漏洞探测 | kube-hunter | 扫描已知K8s暴露点和配置缺陷 | 只作为线索来源，不能代替手工验证 |
| 攻击利用 | kubeletctl | 简化kubelet API调用，远程exec任意Pod | 依赖10250端口是否可达 |
| 攻击利用 | cdk | 容器环境利用工具箱，含逃逸辅助和端口转发 | 静态编译，适合传入无包管理的容器 |
| 横向移动 | etcdctl | 读取etcd中的数据，获取集群全部状态 | 只在etcd未授权或拿到证书后使用 |
| 辅助后渗透 | metasploit | 生成handler和载荷，用于后续会话管理 | 在云原生场景下更多作为备选 |
选择这些工具的核心逻辑是：K8s安全测试的大部分路径都可以用“kubectl + curl + jq”完成，专用工具只是把容易出错的手工流程封装起来。比如kubeletctl把kubelet的/run、/exec接口封装成简单子命令，省去了大量构造HTTP请求的时间。cdk的优势是单文件、静态编译，可以直接写进容器里，不需要目标容器有bash或wget。
3. Pod层面的突破口：从应用漏洞到ServiceAccount
3.1 进入Pod后第一件事：确认身份与权限边界
攻击的第一步通常不是K8s漏洞，而是应用层漏洞。反序列化、命令注入、任意文件上传、SSRF，这些都是进入Pod的常见入口。一旦在Pod里拿到了命令执行，第一件事不是急着提权，而是确认自己的身份边界。
默认情况下，K8s会把ServiceAccount的信息挂载到容器的/var/run/secrets/kubernetes.io/serviceaccount/目录下，里面包含token、ca.crt和namespace三个文件。这意味着只要Pod能运行，你就天然持有一个SA的身份。判断自身权限最快的方法是：
cat /var/run/secrets/kubernetes.io/serviceaccount/token cat /var/run/secrets/kubernetes.io/serviceaccount/namespace # 使用curl直接请求API Server APISERVER="https://kubernetes.default.svc" TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token) curl -sk -H "Authorization: Bearer $TOKEN" \ $APISERVER/api/v1/namespaces这一步可以快速确认API Server是否可达、token是否有效、当前SA是否有读取Namespace列表的权限。如果请求返回403，说明当前SA权限很低，这时需要进一步排查是否有其他可用的身份和凭据。
3.2 ServiceAccount与RBAC的常见配置缺陷
在K8s渗透测试里，SA权限评估是决定后续路径的核心。一个常见的错误是开发团队为了方便，把某个应用绑定了cluster-admin角色，或者创建了大量权限宽泛的RoleBinding。另一个常见问题是把跨Namespace的读取权限授予了业务Pod，导致攻击者拿到一个低权限SA后，可以读取其他命名空间的Secret和ConfigMap。
检查SA权限的黄金命令是：
kubectl auth can-i --list这条命令会返回当前身份所有的权限列表。实际测试中我遇到过的情况：某个SA只有get pods权限，但它在default命名空间的某个Secret里存着数据库密码，而那个Secret又恰好可以被该SA读取。这种“业务层面的越权”用工具链是不好扫出来的，必须靠信息收集阶段对资源内容的逐个检查。所以在拿到Pod Shell后，不要急着提权，先把当前SA能读的东西全部翻一遍，ConfigMap、Secret、ServiceAccount列表、RoleBinding列表，每一步都可能找到高价值信息。
3.3 从Pod内提取高价值敏感信息
除了RBAC权限，Pod内部环境变量、挂载配置、命令行参数也值得翻找。很多应用通过环境变量向容器传递数据库连接、Redis密码、第三方API Key，这些在攻击者眼里就是第一桶金。检查顺序通常是：
# 环境变量中的敏感信息 env | grep -i -E 'pass|secret|token|key|mysql|redis|mongo' # 挂载的敏感目录 mount | grep -E '/var/run/secrets|/etc/kubernetes' # 可能存在的Kubeconfig find / -name "kubeconfig" -o -name "*.conf" 2>/dev/null # 容器内的网络信息，判断是否能访问metadata服务 ip addr show eth0 cat /etc/resolv.conf如果Pod允许访问云厂商的metadata服务（通常是169.254.169.254，阿里云是100.100.100.200），还需要尝试请求metadata获取实例的身份凭证。很多Pod配置了hostNetwork或者底层网络策略宽松，导致可以直接访问到宿主机的metadata地址。拿到节点的云凭证，后续结合云平台API，效果不亚于拿到Node root权限。
4. 横向移动的核心：拿下kubelet API，从Pod到Node
4.1 kubelet 10250端口为什么是攻击者的好朋友
K8s每个Node上都有一个kubelet进程，它除了接受API Server的调度指令外，还暴露了10250和10255两个端口。10255这是只读端口，提供cAdvisor等指标信息。10250是真正的操作端口，kubelet通过它提供/pods、/logs、/exec、/run等接口。也就是说，只要你能请求10250，就相当于可以在节点上任意Pod里执行命令。
历史版本里kubelet默认是允许匿名访问的，后来因为安全问题，官方在1.6之后逐步收紧，要求认证。但实际环境里仍然存在大量错误配置，常见的有三种：第一是--anonymous-auth=true配合--authorization-mode=AlwaysAllow，相当于把kubelet完全裸奔；第二是RBAC把system:anonymous用户绑定到了system:node角色；第三是把kubelet的证书配置错误，导致任何人都可以以节点身份调API Server。最直接的检测命令是：
curl -sk https://NODE_IP:10250/pods如果返回了Pod列表的JSON，说明匿名访问可用；如果返回403，则说明有认证拦截。当匿名访问不可用时，还可以尝试用容器内已有的token或证书去请求10250端口，因为有些环境配置了kubelet对本地SA的信任。
4.2 kubeletctl的使用：远程exec任意Pod
当确认10250端口可访问后，kubeletctl会大大提升效率。它会把裸HTTP请求封装成好用的命令，核心用法是：
# 枚举节点上所有Pod kubeletctl pods -i # 在指定Pod中执行命令 kubeletctl exec "id" -p nginx-deploy-xxxxx -c nginx -n default # 列出敏感路径 kubeletctl scan这里的“远程exec”很有攻击性，因为kubelet API不会像kubectl那样校验你是否有pods/exec权限，只要kubelet配置允许匿名调用，你就能对节点上的任意容器执行命令。实际测试中，我用这个接口突破了那些只有低权限SA或者应用存在命令注入的困境。kubeletctl的scan子命令会检查常见的kubelet敏感路径是否存在，比如/configz、/pods、/exec、/logs等，可以快速判断哪些接口暴露可以进一步利用。
4.3 从Pod到Node的路径：hostPID、hostNetwork与特权容器
除了kubelet API，Pod自身的安全上下文配置也经常成为横向移动的跳板。有些业务为了性能或者操作方便，给Pod开了hostPID: true、hostNetwork: true，甚至是privileged: true。如果你拿到的Pod有这些配置，提权几乎就是一步的事。创建一个特权容器，挂载宿主机根目录，然后写SSH公钥或直接替换宿主机的cron任务，这些手法在生产测试中要格外谨慎，因为对业务影响巨大，必须有明确授权且先与客户确认操作边界。
从权限利用的角度看，在具备create pods权限的情况下，即使当前Pod没有特权，也可以尝试创建一个新的特权Pod来接管节点。通过K8s API提交一个Pod定义，挂载宿主机的根目录到容器里，就能直接读写节点文件系统：
cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: pwn-node namespace: kube-system spec: hostPID: true hostNetwork: true containers: - name: pwn image: alpine command: ["/bin/sh"] args: ["-c", "sleep 3600"] volumeMounts: - name: rootfs mountPath: /host securityContext: privileged: true volumeMounts: - name: rootfs mountPath: /host volumes: - name: rootfs hostPath: path: / EOF需要特别提醒，kube-system命名空间通常权限控制更严，能否创建Pod取决于RBAC。如果在普通命名空间也能以服务账号创建Pod，同样可以用hostPath挂载节点根目录，区别只是需要确认ImagePullPolicy和网络策略不会阻碍。
4.4 从Node到控制面：翻找证书与Kubeconfig
拿到Node Shell后，最优先做的是翻找控制面的配置文件和证书。K8s节点上通常存在/etc/kubernetes目录，里面存放kubelet.conf、kubeconfig和各类证书。这些文件如果权限配置不当，攻击者就能直接读取到节点身份证书，进而以合法节点身份与API Server通信。
具体路径因集群安装方式而异。二进制部署的集群，证书一般分散在/etc/kubernetes/pki/下；使用kubeadm部署的集群，会在/etc/kubernetes/下生成kubeconfig文件；通过Rancher创建的集群，则可能在/var/lib/rancher/下存在集群配置。我建议的检查顺序是：
# 查找节点上的Kubeconfig find / -name "*.kubeconfig" -o -name "*kubeconfig*" -o -name "kubelet.conf" 2>/dev/null # 查看kubelet进程参数，了解控制面地址和证书路径 cat /proc/$(pgrep kubelet)/cmdline | tr '\0' ' ' # 读取kubelet客户端证书 ls -la /var/lib/kubelet/pki/ openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -noout -text拿到kubelet客户端证书后，可以尝试用它请求API Server。在RBAC配置宽松的环境中，system:nodes组可能被授予了超出预期的高权限，从而直接读取集群Secret或创建高权限对象。不过更多时候，kubelet证书的权限有限，需要继续找别的路。
5. 直取集群管理员：控制面高危配置与提权路径
5.1 从高权限SA到cluster-admin
如果整个链路走到了API Server这一层，那么离集群管理员通常只差一步。这里我指的“API Server这一层”，是指你已经有了一个可以向API Server发起请求的身份，无论它是Pod的SA token、节点的kubelet证书，还是一个偷来的kubeconfig。接下来要做的就是对RBAC做地毯式检查。
核心是检查ClusterRoleBinding和RoleBinding是否存在过度授权。很多环境里，某个管理员的账号或某个系统组被绑定了cluster-admin，而且绑定对象的范围很广，比如绑给了所有经过认证的用户。如果发现某个namespace下的默认SA绑定到了高权限角色，同时攻击者又能创建Pod，那就可以通过创建Pod来借用这个高权限SA的身份：
# 查看所有clusterrolebinding kubectl get clusterrolebinding -o json | jq '.items[] | {name, roleRef, subjects}'实际操作中我碰到过一个很典型的案例：某集群的kube-system命名空间下有个SA被绑定到了cluster-admin，同时有一个普通命名空间的RoleBinding把system:serviceaccount:kube-system:default作为subject，并且攻击者控制的SA拥有创建Pod的权限。于是我在kube-system下创建了一个Pod，挂载了那个高权限SA的token，再用它调用API Server，权限立刻变成cluster-admin。这个案例说明，K8s的权限边界不是看单个绑定，而是看整个RBAC链路的可达性。
5.2 etcd未授权访问：集群的全部秘密
etcd是K8s的状态存储，里面保存了集群所有的配置、Secret、ServiceAccount token和RBAC绑定。如果etcd端口（默认2379或2380）暴露在网络可达的位置且没有启用TLS认证，或者在节点本地可以直接访问，那么获取集群管理员权限就是分钟级的事。
使用etcdctl读取集群数据需要指定API版本，K8s 1.6之后etcd基本是v3协议：
export ETCDCTL_API=3 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 | grep -i secret如果没有证书，也可以在etcd未启用TLS的情况下用etcdctl --endpoints=http://127.0.0.1:2379尝试。拿到etcd中保存的Secret明文后，重点提取kube-system命名空间下的token，尤其是那些绑定了cluster-admin角色的。直接读取/registry/secrets/kube-system/下的数据，或者通过etcd中存留的各类ServiceAccount token来构造新的API请求，都可以快速拿到管控权。
5.3 通过控制面组件配置漏洞提权：kube-controller-manager与Dashboard
除了etcd，控制面的其他组件也可能成为提权路径。kube-controller-manager挂载了服务端证书，如果它的--kubeconfig权限过宽，一旦能通过SSRF或其他方式请求到它的端口，就可能伪造控制器对象。不过这种方式对网络可达性要求很高，实际测试中更常见的是Dashboard的匿名访问和弱口令问题。
K8s Dashboard如果以NodePort或LoadBalancer暴露，同时启用了匿名访问或者使用了默认的自签证书，攻击者就可以直接打开Dashboard界面，尝试常见的弱口令，或在没有任何认证的情况下查看集群资源。Dashboard的问题是它把集群操作从命令行变成了图形界面，攻击难度大大降低，所以很多红队工具里也会自动探测/api/v1/namespaces/kube-system/services/kubernetes-dashboard路径。另外，Helm Chart中经常残留高权限ServiceAccount名称和tokens，很多部署文档里为了省事直接用--set serviceAccount.clusterAdmin=true，这种配置如果恰好暴露了tiller服务，旧版本甚至可以直接通过tiller调用K8s API。
5.4 一条完整的提权路径示例
为了让你更直观理解整条攻击链如何串联，我给出一个典型的实战场景。它不一定是最高级的利用方式，但能清晰体现工具链的环环相扣。
首先是信息收集。攻击者通过一个Web应用的命令注入漏洞进入Pod，确认当前SA为default:default，权限只有get pods。然后使用curl请求API Server，检查集群版本和各Namespace的Pod列表。接着漏洞探测发现某个Node的kubelet匿名访问没有关闭，于是通过kubeletctl读取该节点上所有Pod的列表，并通过kubelet的exec接口在另一个运行的Pod中执行命令，拿到了那个Pod绑定的SA token。那个SA恰好在kube-system下拥有创建Pod的权限，于是通过K8s API在kube-system命名空间创建了一个挂载高权限SA token的特权容器，用hostPath挂载宿主机根目录，在节点上读取了kubelet的客户端证书和kubeconfig文件。最后，利用这个节点的身份请求API Server，成功发现了某个ClusterRoleBinding把system:serviceaccount:kube-system:default绑定到了cluster-admin，于是直接切换为该SA的token，获取了集群管理员权限。整个过程只用到了kubectl、curl、kubeletctl和一段YAML，没有复杂的0day。
6. 工具链整合：从手工命令到可复用脚本
6.1 三个关键脚本串联信息收集
反复手敲命令费时又容易漏项，我会在授权测试中把常用的检查逻辑写成脚本，来提高效率。下面这个脚本用来快速判断当前Pod身份能做哪些操作：
#!/bin/bash # quick_enum.sh - 快速枚举当前Pod的K8s权限 APISERVER="https://kubernetes.default.svc" TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token) NAMESPACE=$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace) echo "[*] Namespace: $NAMESPACE" # 尝试读取自身权限 kubectl auth can-i --list 2>/dev/null || \ curl -sk -H "Authorization: Bearer $TOKEN" \ $APISERVER/api/v1/namespaces/$NAMESPACE/pods # 尝试读取当前namespace的configmap和secret for resource in configmaps secrets endpoints; do echo "[*] Checking $resource" curl -sk -H "Authorization: Bearer $TOKEN" \ $APISERVER/api/v1/namespaces/$NAMESPACE/$resource | jq '.items | length' done # 检测kubelet 10250端口 ip route | grep default结合kubeletctl scan和kube-hunter的探测结果，可以在几分钟内拿到集群的基础安全画像，再根据结果决定下一步走哪条路径。
6.2 一个轻量级的检查清单checklist
为了减少临场失误，我整理了一份操作checklist。它在渗透测试中非常实用，也可以作为K8s安全自查的参考。
- 确认当前Pod的SA身份和权限（
kubectl auth can-i --list）。 - 检查所有可读取的ConfigMap和Secret是否有敏感信息。
- 探测API Server地址和版本，判断是否存在已知的未授权访问漏洞。
- 枚举当前命名空间及所有可访问命名空间的Service和Pod。
- 检查Pod是否能访问云metadata服务。
- 探测宿主机IP和kubelet 10250/10255端口是否可达。
- 若kubelet可访问，通过kubeletctl枚举节点上的Pod并尝试exec。
- 拿到节点权限后，翻找kubeconfig、证书、etcd证书和控制器配置文件。
- 尝试访问etcd的2379端口，确认是否有TLS认证。
- 遍历ClusterRoleBinding和RoleBinding，寻找过度授权。
- 若发现低权限SA绑定了高权限角色，尝试创建Pod借用身份。
这个checklist的价值在于，它强制按照“身份→网络→数据→控制面”的顺序推进，最大限度避免在一个环境里东一榔头西一棒子。有一次我面对一个网络策略极其严格的集群，kubelet不可达、API Server也只能从Pod内访问，就是靠着逐项核对checklist，在最后一步找到了某SA绑定了过宽的ClusterRole，才突破到管理员。
6.3 C2与远控工具在K8s环境的适配问题
在K8s环境里使用传统C2工具（比如Metasploit的handler和meterpreter）并不总是最优解。容器环境天生短暂，Pod随时可能被重新调度或删除，传统C2的会话稳定性反而成了问题。而且很多集群启用了东西向流量安全监控，一个容器频繁向外发长连接很容易被安全设备标记。
我的经验是，K8s环境的“会话保持”更适合用轻量级方案：比如静态编译的agent二进制，通过DNS或者HTTPS做短连接回连，或者通过K8s API自身来做“后门”——比如创建一个Deployment，让它定时拉取镜像并从镜像中执行命令。这种方式的好处是流量形态和正常业务请求一致，不容易触发告警。不过，在做授权测试时，我们通常不会做太深的权限维持，而是以验证风险存在为目标。这一点和实际攻击行为有本质区别。
7. 常见问题与排查经验速查
7.1 环境受限时的替代方案
K8s渗透测试遇到的环境约束五花八门，这里分享几个高频问题和我的排查思路。
| 问题 | 可能原因 | 替代方案 |
|---|---|---|
| 容器里没有bash也没curl | 基础镜像被裁剪 | 尝试sh、python、perl，或利用/dev/tcp手工建TCP连接 |
| kubelet 10250返回403 | 已启用认证或RBAC拦截 | 尝试用SA token请求该端口，或换其他Node继续探测 |
| 当前SA权限极小，连Pod列表都读不了 | RBAC收紧 | 翻环境变量、已挂载Secret、检查metadata服务，尝试SSRF |
| 无法访问API Server的6443端口 | 网络策略限制 | 检查集群DNS域名，尝试通过Service条目或NodePort外联 |
| etcd端口被防火墙屏蔽 | 网络隔离 | 在Node本地执行ss -lntp，确认是否走TLS，尝试从节点本地访问 |
| 拿到证书但API Server拒绝 | 证书过期或RBAC限制 | 查看证书有效期和subject，寻找其他身份凭据 |
7.2 在Pod内传输工具的三个技巧
渗透测试中经常要在Pod和攻击机之间传文件，但容器里往往没有scp、nc这些工具，网络策略也可能限制访问。我常用的方法：
第一种是kubectl cp。如果你已经通过K8s API操作Pod，kubectl cp ./tool.sh default/pod-name:/tmp/tool.sh是最省事的。第二种是利用已有的Web应用漏洞特征，比如目标Web应用本身支持文件上传或下载，借助这个功能完成文件交换。第三种是启动一个临时HTTP服务，在Pod内用wget、curl或者python -c来拉取。如果Pod连出网都受限，可以先在一个可以出网的Pod上把工具下载好，再通过kubelet exec把文件复制到目标Pod。
7.3 低权限环境下的信息收集技巧
遇到权限很低的SA时，不要急着放弃。K8s的API Server对未授权请求有时会返回部分信息，比如请求/version、/api并只需要认证但不需要授权就能成功，可以获取集群版本和API路径。另外，即使无法读取Pod列表，也可以尝试通过DNS枚举Service名称的方式推断集群里跑的业务。比如dig svc.namespace.svc.cluster.local，很多环境里Service名称本身就能泄露内部应用架构。另一种方式是查看当前Pod的/etc/resolv.conf里的search域，确认包含哪些namespace，再根据这些namespace名称（如jenkins、gitlab、monitoring）推断集群内可能存在的敏感服务，然后通过Service DNS去请求。
8. 防御视角：这条工具链教会我什么
从我多次做K8s渗透测试的经验看，能够打通的链路，往往不是靠0day，而是靠配置叠加。默认的ServiceAccount token被挂载到业务容器，很少有人去关；kubectl的low权限用户却意外绑定了高权限角色，很少有人去审计；kubelet的匿名访问在测试环境里开了一堆，上线时忘记收敛，这些才是攻击链能够落地的基础。
对这整条工具链的防御建议就三条。第一，严格落实最小权限：业务Pod尽量挂载专用的低权限ServiceAccount，关掉默认token的自动挂载（automountServiceAccountToken: false），给匿名用户和system:unauthenticated组做个全局拒绝策略。第二，网络层面对外收敛：kubelet 10250端口只允许API Server网段访问，etcd不和业务网络互通，API Server对公网做IP白名单。第三，审计巡检要常态化：定期检查ClusterRoleBinding是否有异常绑定，扫描集群里有没有privileged容器，追踪所有Secret的读取日志。这三条做到了，上面讲的很多路径就会被切断。
最后再分享一点个人的体会：K8s渗透测试工具链的价值，不在于某一个工具的先进性，而在于你能否在正确的阶段选择正确的工具，并把它们串联成一条完整的攻击路径。从Pod到集群管理员，每一层都是身份和权限的博弈，你越了解K8s本身的运行机制，工具链就越顺手。这也是为什么我很少依赖重型扫描器，更多是用kubectl、curl和kubeletctl这些最基础的工具，因为它逼着你去理解每一步背后的原理。希望这篇文章能给你一些启发，让你在云原生安全的路上少走几步弯路。
