尧图网站建设 
从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绑定的ServiceAccountSA权限而不是节点权限更不是集群权限。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层面的突破口从应用漏洞到ServiceAccount3.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 APISERVERhttps://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到Node4.1 kubelet 10250端口为什么是攻击者的好朋友K8s每个Node上都有一个kubelet进程它除了接受API Server的调度指令外还暴露了10250和10255两个端口。10255这是只读端口提供cAdvisor等指标信息。10250是真正的操作端口kubelet通过它提供/pods、/logs、/exec、/run等接口。也就是说只要你能请求10250就相当于可以在节点上任意Pod里执行命令。历史版本里kubelet默认是允许匿名访问的后来因为安全问题官方在1.6之后逐步收紧要求认证。但实际环境里仍然存在大量错误配置常见的有三种第一是--anonymous-authtrue配合--authorization-modeAlwaysAllow相当于把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 APIPod自身的安全上下文配置也经常成为横向移动的跳板。有些业务为了性能或者操作方便给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_API3 etcdctl --endpointshttps://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 --endpointshttp://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.clusterAdmintrue这种配置如果恰好暴露了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权限 APISERVERhttps://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操作Podkubectl 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这些最基础的工具因为它逼着你去理解每一步背后的原理。希望这篇文章能给你一些启发让你在云原生安全的路上少走几步弯路。 K8s渗透测试工具链实战：从Pod到集群管理员
从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绑定的ServiceAccountSA权限而不是节点权限更不是集群权限。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层面的突破口从应用漏洞到ServiceAccount3.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 APISERVERhttps://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到Node4.1 kubelet 10250端口为什么是攻击者的好朋友K8s每个Node上都有一个kubelet进程它除了接受API Server的调度指令外还暴露了10250和10255两个端口。10255这是只读端口提供cAdvisor等指标信息。10250是真正的操作端口kubelet通过它提供/pods、/logs、/exec、/run等接口。也就是说只要你能请求10250就相当于可以在节点上任意Pod里执行命令。历史版本里kubelet默认是允许匿名访问的后来因为安全问题官方在1.6之后逐步收紧要求认证。但实际环境里仍然存在大量错误配置常见的有三种第一是--anonymous-authtrue配合--authorization-modeAlwaysAllow相当于把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 APIPod自身的安全上下文配置也经常成为横向移动的跳板。有些业务为了性能或者操作方便给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_API3 etcdctl --endpointshttps://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 --endpointshttp://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.clusterAdmintrue这种配置如果恰好暴露了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权限 APISERVERhttps://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操作Podkubectl 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这些最基础的工具因为它逼着你去理解每一步背后的原理。希望这篇文章能给你一些启发让你在云原生安全的路上少走几步弯路。