⚠️ 严正声明

本文内容仅用于网络安全攻防研究与教育目的。文中所述技术原理旨在帮助开发与运维人员理解配置风险，从而加固系统。严禁利用相关技术对非授权目标进行扫描或攻击，否则法律后果自负！

---

🕵️‍♂️ 前言：最危险的“方便”

在云原生时代，Docker 和 Kubernetes (K8s) 构成了基础设施的基石。很多开发同学为了图方便（比如要在容器里编译 Docker 镜像，或者挂载硬件驱动），习惯性地加上 --privileged 或者在 YAML 里配置 privileged: true。

这个开关，被称为容器安全的“核按钮”。

上周，在一次授权的内部红队演练中，我发现目标集群的一个 CI/CD Runner 容器开启了特权模式。对于攻击者来说，这哪里是容器，这简直是通往宿主机 Root 权限的敞开大门。

今天，我就以第一人称视角，复盘我是如何利用这个配置失误，在 5 分钟内实现**容器逃逸（Container Escape）**并接管宿主机的。

---

🧠 深度原理：特权模式 (Privileged) 到底意味着什么？

当容器以特权模式启动时，Docker 会移除所有安全限制：

1. Capabilities 全开：容器获得了所有的 Linux 内核能力（如 CAP_SYS_ADMIN），这意味着它可以挂载文件系统、加载内核模块、操作 iptables。
2. 设备访问权：容器可以访问宿主机 /dev 下的所有设备文件（包括硬盘）。
3. 安全机制失效：AppArmor 和 Seccomp 等安全配置文件被禁用。

一句话总结：特权容器本质上就是一个没有隔离的 Root 进程，它和宿主机之间只隔了一层窗户纸。

---

⚔️ 攻击复盘：从容器到宿主机的“越狱”之路

假设通过 Web 应用漏洞（如 RCE），我已经拿到了该容器的 Shell 权限。接下来就是标准的逃逸流程。

Step 1: 环境踩点（我是谁？）

首先，我需要确认自己是否处于特权容器中。
查看 Linux Capabilities（能力值）：

# 查看当前进程的能力
capsh --print

如果输出中包含 Current: = ... cap_sys_admin ... 或者解码后的掩码是 0000003fffffffff，那么Bingo！这是一个特权容器。

Step 2: 扫描宿主机磁盘

既然拥有设备访问权，我可以直接列出宿主机的硬盘分区：

fdisk -l

通常，我会寻找类似 /dev/sda1、/dev/vda1 这种容量较大的分区，这通常是宿主机的根文件系统。

Step 3: 挂载宿主机根目录（关键一击）

这是逃逸的核心步骤。利用 CAP_SYS_ADMIN 能力，我可以将宿主机的磁盘挂载到容器内部的一个目录上。

# 1. 创建挂载点
mkdir /tmp/host_root

# 2. 强行挂载宿主机磁盘 (假设宿主分区为 /dev/vda1)
mount /dev/vda1 /tmp/host_root

此时，边界已经被打破。
通过 /tmp/host_root 目录，我可以读写宿主机上的任何文件。

• 窃取凭证：cat /tmp/host_root/etc/shadow
• 查看配置：cat /tmp/host_root/root/.kube/config

Step 4: 灵魂附体 (Chroot)

仅仅读写文件还不够，我需要在宿主机上执行命令。
利用 chroot 命令，我可以将当前进程的根目录“切换”到挂载点。

# 切换根目录到宿主机挂载点，并启动一个 Shell
chroot /tmp/host_root /bin/bash

执行完这条命令后，虽然我还在容器的终端里，但我的文件系统上下文已经完全变成了宿主机。
此时输入 ps -ef，看到的不再是容器进程，而是宿主机上所有的进程（如 kubelet, sshd）。

攻击路径可视化：

---

🛡️ 防御策略：如何焊死牢笼？

作为防守方（Blue Team），我们需要构建多层防御体系来应对这种风险。

1. 策略准入 (Policy Enforcement) —— 最有效

在 K8s 集群层面，通过准入控制器（Admission Controller）直接拦截掉所有请求特权模式的 Pod。

可以使用 OPA Gatekeeper 或 Kyverno。

Kyverno 拦截策略示例：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged-containers
spec:
  validationFailureAction: enforce # 强制拦截
  rules:
  - name: validate-privileged
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "生产环境严禁使用特权容器！"
      pattern:
        spec:
          containers:
          - securityContext:
              privileged: false

2. 最小权限原则 (Least Privilege)

如果确实需要某些内核能力（比如修改网络配置），不要给 privileged: true，而是使用 cap_add 按需添加。

# 推荐做法：只给网络管理权限，不给特权模式
securityContext:
  capabilities:
    add: ["NET_ADMIN"]

3. 运行时监控 (Runtime Security)

如果攻击者绕过了静态检测，我们需要在运行时发现异常行为。
使用 Falco 监控异常系统调用。当容器内部执行 mount 或 chroot 时，立即触发报警。

# Falco 规则：检测特权容器启动
- rule: Launch Privileged Container
  condition: container and container.privileged=true
  output: "Privileged container launched (user=%user.name command=%proc.cmdline)"
  priority: WARNING

---

📝 结语

容器逃逸并不是什么高深的黑魔法，往往源于开发者为了“图方便”而留下的配置后门。

DevOps 不能只追求速度，而忽视了 Security。
--privileged 就像一把万能钥匙，它确实能解决很多权限问题，但同时也把这把钥匙交给了潜在的入侵者。

请记住：绝大多数应用，都不需要特权模式。