2026-07-08 04:56:12 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文系统梳理了容器与K8s攻击链，从镜像供应链投毒、配置错误到运行时逃逸及权限滥用，并给出三层防御体系：准入控制、运行时监控与RBAC最小权限。文章强调配置错误是头号风险，privileged模式与docker.sock挂载极易导致逃逸，并提供了可立即执行的检查清单，如Trivy扫描、kube-bench审计等。 综合评分： 87 文章分类： 供应链安全,安全运营,红队,漏洞分析,渗透测试

cover_image

容器&K8s攻防全链路：从镜像投毒到集群提权沦陷

原创

安全值班室安全值班室

安全值班室

2026年7月6日 09:00 河北

在小说阅读器读本章

去阅读

📊 一组数据 2025年Aqua Security报告：68%的组织在过去一年遭遇过容器安全事件，其中42%来自供应链攻击——恶意镜像。CNCF同期调查：73%的人认为K8s配置错误是头号风险，但只有30%的团队在做自动化RBAC审计。

容器化不是安全免责牌，它是攻击面的放大器。今天不扯概念，直接拆攻击路径和防守方案。不管是蓝队自查还是红队突破，这篇文章都值得收藏。

📌 攻击链全景镜像构建 → 镜像仓库 → 部署配置 → 运行时逃逸 → 集群权限提升。任何一个环节漏了，整条链都可能被攻破。

一、容器与K8s：攻击面全景▎ 1.1 镜像层：供应链投毒2025年6月Aqua Nautilus披露的案例最能说明问题：攻击者通过窃取Docker Hub维护者凭证，往300多个热门镜像（node、python、nginx）里植入了后门，累计被拉取超过150万次。你pull了node:latest，跑起来的是一个已经被植入后门的镜像。更隐蔽的是「依赖投毒」——基础镜像在构建时下载了一个被篡改的PyPI包。你从Dockerfile COPY进去的源代码是干净的，但运行环境已经脏了。2025年4月Coinbase的供应链事件就是典型案例：CI管道从Docker Hub拉了一个被篡改的curl工具镜像，攻击者利用CVE-2025-1015（containerd容器逃逸漏洞）实现了反弹Shell。从投毒到逃逸，整个攻击链没有触发任何告警。

🛡️ 防守要点 • 只从受信任的镜像仓库拉取，用Cosign做镜像签名验证，未签名的镜像拒绝部署 • 用Trivy/Grype做镜像漏洞扫描，准入策略阻断高危镜像部署 • 锁定基础镜像版本（不用latest标签），建立基础镜像更新机制

▎ 1.2 配置层：K8s配置错误CNCF的数据很直白：K8s配置错误是头号风险，没有之一。最常见的高危配置就这几条：

| 配置项 | 风险 | 后果 | | — | — | — | | privileged: true | 🔴 高危 | 容器拥有宿主机全部内核能力 | | 挂载docker.sock | 🔴 高危 | 容器内可直接操作Docker守护进程 | | hostNetwork: true | 🟠 中危 | 共享宿主机网络命名空间 |

# 查找高危Pod
kubectl get pods -A -o json | grep -A5 'privileged.*true'
kubectl get pods -A -o json | grep docker.sock

privileged模式 + docker.sock = 容器逃逸，不是概率问题，是时间问题。逃逸后攻击者获得宿主机权限，可以访问同主机上所有其他容器。▎ 1.3 运行时层：容器逃逸两个值得关注的容器逃逸漏洞：CVE-2025-1015 — containerd的runc组件syscall过滤绕过，CVSS 7.5。2025年2月修复（containerd 2.0.2）。利用代码在GitHub公开后72小时内就有在野利用报告。CVE-2025-0145 — Docker Engine的overlay网络漏洞，CVSS 7.5。2025年1月修复（Docker 25.0.6）。攻击者通过构造特殊的网络请求触发逃逸。利用链：从容器内部 → 利用内核漏洞或配置缺陷 → 逃逸到宿主机 → 横向移动到其他Pod或节点。每一步都有对应的检测手段，但如果没有配置，就等于给攻击者开了绿灯。二、K8s权限滥用：比容器逃逸更隐蔽的攻击2025年3月Grafana Labs的真实案例是最佳警示：攻击者发现了一个「只读」ServiceAccount，表面看权限很低——但这个SA同时有list secrets和pods/exec权限。前者可以列所有Secret（包括数据库密码、云API密钥、TLS证书），后者可以在任何Pod里执行命令。一个「只读」账号，变成了全集群控制权。攻击者先列了所有Secret拿到AWS密钥，然后通过pods/exec在Pod中执行了数据窃取命令，整个过程没有触发任何基于RBAC的告警——因为这些操作在API层面都是「合法的」。

⚠️ 这是K8s权限模型的核心问题权限检查是平面的，不是立体的。list secrets本身不是高危操作，pods/exec也不是。但两者结合，加上kubectl的强大能力，就成了灾难。单独审查每个权限都「合规」，组合起来就是一次集群沦陷。

三、防守方案：三层防御体系▎ 3.1 准入控制（第一道门）用Kyverno或OPA做策略即代码。举例：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged
spec:
  validationFailureAction: Enforce
  rules:
    - name: privileged-containers
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "不允许使用privileged容器"
        pattern:
          spec:
            containers:
              - securityContext:
                  privileged: "false"

一行YAML阻止所有privileged容器，比安全团队review一千行Deployment配置都有效。▎ 3.2 运行时监控（第二道门）用Falco做运行时异常检测。最有价值的一条规则：当容器内部执行kubectl命令时告警。正常业务容器不会跑kubectl，这大概率是攻击者在做横向探测。

- rule: Detect Kubectl in Container
  condition: spawned_process
    and container and proc.name=kubectl
  output: "kubectl in container (image=%container.image)"
  priority: WARNING

Falco的eBPF探针无侵入式运行，对性能影响通常在1-3%以内。▎ 3.3 RBAC最小权限（第三道门）CIS Kubernetes Benchmark关键检查项：

❌ 禁止 secret的list权限给非管理员 → 用get+名称精确引用 ❌ 禁止 pods/exec权限给普通服务 → 调试用telepresence替代 ❌ 禁止 cluster-admin绑定给非必要账号 → 按namespace授权 ❌ 禁止 匿名访问 → API Server设置--anonymous-auth=false ❌ 禁止 kubelet只读端口 → 关闭10255，10250必须设置认证

一条有用的经验：每季度跑一次kubectl describe clusterrolebinding，看看哪些ServiceAccount绑了cluster-admin。很多时候你会发现三年前的CI账号还挂着管理员权限。四、一周内能做的事别想着一步到位上Falco+Kyverno+OPA全栈。下面这五件事，一个下午能做完：

1️⃣ Trivy扫现有镜像 — trivy image nginx:latest看看你正在用的基础镜像有多少漏洞。很多人扫完发现用了两年的nginx:1.25有30+个已知CVE。 2️⃣ kube-bench跑CIS检查 — kube-bench run --targets=master,node看你的集群CIS评分。大部分集群首次跑分在40-60分之间。 3️⃣ 审计ServiceAccount权限 — kubectl get rolebindings,clusterrolebindings -A -o yaml导出所有绑定权限，重点关注cluster-admin绑定。 4️⃣ 查privileged容器 — kubectl get pods -A -o json | grep -A5 'privileged.*true'看看有没有容器在特权模式下运行。 5️⃣ 查docker.sock挂载 — kubectl get pods -A -o json | grep docker.sock看看哪些容器挂了docker.sock。 6️⃣ 配置网络策略 — 默认K8s允许所有Pod间通信。加一条默认拒绝入站出站的NetworkPolicy，然后按需放行。这一步能直接阻断90%以上的横向移动攻击。

觉得有用？点个在看支持一下

📌 值班员说容器安全不是买一台扫描器就能解决的问题。它需要从镜像供应链到运行时逃逸再到权限模型，三层防御同时上线。下期我们聊聊K8s下的网络策略和微隔离——如何在零信任架构下，让Pod之间的通信不再是一场裸奔。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全值班室安全值班室安全值班室《容器&K8s攻防全链路：从镜像投毒到集群提权沦陷》