容器逃逸的七条路径：Docker 安全加固的攻防实战

一、从容器到宿主机：一次真实的容器逃逸事件复盘

某生产环境的容器被植入挖矿脚本后，攻击者仅用 3 分钟就从容器内部获取了宿主机的 root 权限。事后排查发现，该容器的 Dockerfile 中有一行 volumes: /:/host，将宿主机根目录挂载到容器内。攻击者在容器内执行 chroot /host，直接切换到宿主机的文件系统，完成逃逸。

这不是极端案例。容器安全的本质问题在于：容器共享宿主机内核，内核漏洞或配置失误都可能成为逃逸通道。Docker 默认配置只提供"命名空间隔离"，而非"安全边界"。把容器当虚拟机用，是最大的安全错觉。

本文从攻击者视角出发，梳理容器逃逸的七条常见路径，并给出每条路径的防御方案。

二、容器逃逸路径与防御架构

flowchart TD
    subgraph 逃逸路径
        A[路径1: 特权容器] --> H[宿主机 root]
        B[路径2: 危险挂载] --> H
        C[路径3: 内核漏洞] --> H
        D[路径4: Docker Socket 暴露] --> H
        E[路径5: Capabilities 滥用] --> H
        F[路径6: 命名空间泄漏] --> H
        G[路径7: 共享 PID/Network Namespace] --> H
    end

    subgraph 防御层
        L1[第1层: 最小权限镜像] --> L2[第2层: SecurityContext 约束]
        L2 --> L3[第3层: Seccomp/AppArmor 策略]
        L3 --> L4[第4层: 运行时检测 Falco]
    end

    A -.->|防御| L2
    B -.->|防御| L1
    C -.->|防御| L3
    D -.->|防御| L2
    E -.->|防御| L2
    F -.->|防御| L3
    G -.->|防御| L2

    style H fill:#ff6b6b,color:#fff
    style L4 fill:#51cf66,color:#fff

三、七条逃逸路径的防御代码实现

3.1 路径 1：特权容器——最危险的默认配置

# 错误示例：privileged: true 等于关闭所有安全隔离
# 攻击者在特权容器内可访问所有设备、加载内核模块、修改 iptables
apiVersion: apps/v1
kind: Deployment
metadata:
  name: unsafe-deployment
spec:
  template:
    spec:
      containers:
        - name: app
          securityContext:
            privileged: true  # 危险！等同于宿主机 root

---
# 正确做法：只声明需要的 capabilities，而非全部权限
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hardened-deployment
spec:
  template:
    spec:
      containers:
        - name: app
          securityContext:
            privileged: false
            # 只保留网络绑定权限，而非全部 capabilities
            capabilities:
              add:
                - NET_BIND_SERVICE  # 绑定 1024 以下端口
              drop:
                - ALL  # 先丢弃全部，再按需添加
            readOnlyRootFilesystem: true  # 只读根文件系统，防止写入恶意文件
            runAsNonRoot: true            # 禁止 root 运行
            runAsUser: 1000               # 指定非零 UID

3.2 路径 2：危险挂载——宿主机文件系统暴露

# 错误示例：挂载宿主机敏感路径
volumes:
  - name: host-root
    hostPath:
      path: /           # 挂载根目录——攻击者可 chroot 逃逸
  - name: docker-sock
    hostPath:
      path: /var/run/docker.sock  # 挂载 Docker Socket——攻击者可创建特权容器
  - name: proc
    hostPath:
      path: /proc       # 挂载 procfs——攻击者可读取内核参数

---
# 正确做法：使用 emptyDir 或 ConfigMap/Secret 挂载，避免 hostPath
volumes:
  - name: app-config
    configMap:
      name: app-config   # 只读配置，不可写入恶意文件
  - name: app-data
    emptyDir:
      medium: Memory     # 临时数据用内存盘，不接触宿主机文件系统
  - name: app-secrets
    secret:
      secretName: app-secrets  # Secret 自动挂载为 tmpfs，不落盘

3.3 路径 3：内核漏洞——Seccomp 系统调用过滤

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    {
      "names": [
        "read", "write", "open", "close", "stat", "fstat",
        "poll", "lseek", "mmap", "mprotect", "munmap",
        "brk", "rt_sigaction", "rt_sigprocmask",
        "ioctl", "access", "pipe", "select",
        "madvise", "recvfrom", "sendto",
        "socket", "connect", "accept", "bind", "listen"
      ],
      "action": "SCMP_ACT_ALLOW"
    },
    {
      "names": [
        "keyctl", "add_key", "request_key",
        "bpf", "perf_event_open",
        "ptrace", "process_vm_readv", "process_vm_writev"
      ],
      "action": "SCMP_ACT_ERRNO",
      "comment": "明确禁止与内核密钥环、eBPF、进程调试相关的系统调用——这些是内核漏洞利用的常见入口"
    }
  ]
}

# 在 Pod 中引用自定义 Seccomp Profile
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      securityContext:
        seccompProfile:
          type: Localhost
          localhostProfile: profiles/hardened-seccomp.json

3.4 路径 4：Docker Socket 暴露——最容易被忽略的后门

"""
检测 Docker Socket 是否被异常挂载——防止攻击者通过 Socket 创建特权容器
设计意图：Docker Socket 等于宿主机 Docker 的完整控制权，必须严格限制
"""
import subprocess
import json
import sys

def check_docker_socket_exposure():
    """扫描集群中所有 Pod，检查是否有挂载 docker.sock 的情况"""
    result = subprocess.run(
        ["kubectl", "get", "pods", "-A", "-o", "json"],
        capture_output=True, text=True, check=True
    )
    pods = json.loads(result.stdout)

    violations = []
    for pod in pods["items"]:
        namespace = pod["metadata"]["namespace"]
        name = pod["metadata"]["name"]

        # 检查 volumes 中是否有 hostPath 指向 docker.sock
        for volume in pod["spec"].get("volumes", []):
            host_path = volume.get("hostPath", {}).get("path", "")
            dangerous_paths = [
                "/var/run/docker.sock",
                "/run/docker.sock",
                "/var/run/containerd",
            ]
            if host_path in dangerous_paths:
                violations.append({
                    "namespace": namespace,
                    "pod": name,
                    "path": host_path,
                    "severity": "CRITICAL",
                })

    if violations:
        print("[ALERT] 发现 Docker Socket 暴露：")
        for v in violations:
            print(f"  [{v['severity']}] {v['namespace']}/{v['pod']} -> {v['path']}")
        sys.exit(1)
    else:
        print("[OK] 未发现 Docker Socket 暴露")

if __name__ == "__main__":
    check_docker_socket_exposure()

3.5 路径 5-7：综合防御的 Pod 安全标准

# Pod Security Standards——Restricted 级别配置
# 适用于所有生产环境 Pod，禁止不安全配置
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted
---
# Restricted 级别的 Pod 模板——必须满足以下约束
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      # 必须禁止的配置
      hostPID: false          # 禁止共享宿主机 PID 命名空间（路径7）
      hostNetwork: false      # 禁止共享宿主机网络命名空间（路径7）
      hostIPC: false          # 禁止共享宿主机 IPC 命名空间（路径6）
      containers:
        - name: app
          securityContext:
            allowPrivilegeEscalation: false  # 禁止提权（路径5）
            readOnlyRootFilesystem: true
            runAsNonRoot: true
            runAsUser: 1000
            capabilities:
              drop: [ALL]     # 丢弃全部 capabilities（路径5）

四、安全加固的性能与运维代价

4.1 readOnlyRootFilesystem 的适配成本

只读根文件系统意味着应用不能写入 /tmp、/var/log 等路径。需要为每个需要写入的目录单独挂载 emptyDir：

volumes:
  - name: tmp
    emptyDir: {}           # 替代 /tmp
  - name: cache
    emptyDir:              # 替代 /var/cache
      medium: Memory       # 小文件用内存盘，性能更好
volumeMounts:
  - name: tmp
    mountPath: /tmp
  - name: cache
    mountPath: /var/cache

适配工作量取决于应用的写入路径数量。对于日志，推荐将日志输出到 stdout/stderr，由 Fluentd 采集，而非写入文件。

4.2 Seccomp Profile 的兼容性风险

过于严格的 Seccomp Profile 可能导致应用崩溃。例如，某些 Go 程序依赖 clock_gettime 系统调用，Java 程序依赖 futex。建议先用 SCMP_ACT_LOG 模式运行，记录应用实际使用的系统调用，再据此生成白名单。

4.3 安全与便利的权衡

安全措施	安全收益	运维代价	推荐程度
禁止 privileged	阻断路径1	低	必须
禁止 hostPath	阻断路径2	中	必须
Seccomp 过滤	阻断路径3	高	推荐
禁止 Docker Socket	阻断路径4	低	必须
drop ALL capabilities	阻断路径5	中	推荐
禁止共享命名空间	阻断路径6/7	低	必须
readOnlyRootFilesystem	防止写入恶意文件	中	推荐

五、总结

容器安全的本质不是"容器内安全"，而是"防止从容器逃逸到宿主机"。防御策略遵循最小权限原则：

1. 禁止特权容器：privileged: true 是最大的安全漏洞，生产环境必须禁止。
2. 禁止危险挂载：hostPath 挂载宿主机根目录、Docker Socket、/proc 都是直接逃逸通道。
3. Seccomp 系统调用过滤：限制容器可调用的系统调用，缩小内核漏洞的攻击面。
4. Pod Security Standards：在 Namespace 级别强制执行 Restricted 策略，从准入控制层拦截不安全配置。
5. 运行时检测：用 Falco 监控异常行为（如容器内执行 chroot、加载内核模块），作为最后一道防线。

落地路线：先在所有 Namespace 启用 Pod Security Standards 的 audit 模式，收集违规 Pod 列表；逐个修复后切换到 enforce 模式；再为关键服务添加 Seccomp Profile；最后部署 Falco 做运行时监控。