核心对策是禁用特权模式，同时补上其他关键防护缺口：禁用--privileged、限制capabilities、禁止挂载/docker.sock和敏感路径、以非root用户运行、启用userns-remap、使用只读文件系统，并部署Falco等运行时监控工具。
核心对策是禁用特权模式，同时补上其他关键防护缺口。特权模式（--privileged）本质是给容器配了一把宿主机“万能钥匙”，只要开启，逃逸几乎就是时间问题。
彻底禁用特权模式
除非极特殊场景且已做充分风险评估，否则一律不加 --privileged 启动容器。
- 检查现有容器：运行
docker ps --format "{{.ID}}\t{{.Command}}" | grep privileged，快速定位是否误启特权容器 - 替代方案优先用
--cap-add按需授权，比如只需网络调试就加NET_ADMIN，而非全开 - Kubernetes 中对应字段是
securityContext.privileged: false，必须设为 false 并纳入CI/CD流水线强制校验
阻断常见逃逸路径
即使未开特权，挂载不当仍可能被利用。重点盯住两个高危挂载点：
-
/var/run/docker.sock：禁止挂载进任何业务容器。一旦挂载，容器内可直接调用 Docker API 创建新容器并挂载宿主机根目录 -
/proc、/sys、/dev等敏感路径：除非明确需要，否则不要用-v映射；确需访问设备时，用--device精确指定，而非挂载整个/dev - 检查容器内是否能读写
/etc/passwd或/root/.ssh/authorized_keys，若能，说明挂载了宿主机关键目录，立即修正
运行时权限最小化
让攻击者即使进入容器，也难以立足：
- 容器内默认以非 root 用户运行：Dockerfile 中明确写
USER 1001，避免root权限启动进程 - 启用用户命名空间重映射（userns-remap）：使容器内 UID 1001 映射到宿主机上一个无权限的高位 UID，大幅削弱提权能力
- 使用只读文件系统：加
--read-only启动容器，必要写入路径再用--tmpfs或--volume单独挂载
监控与响应机制
靠预防不能 100% 拦住，得有兜底手段：
- 部署运行时安全工具（如 Falco、Tracee），实时检测异常行为：比如容器内尝试挂载
/、调用mount系统调用、访问/proc/sys/kernel - 审计日志接入 SIEM：重点关注
dockerd日志中创建容器的参数，自动告警含privileged、docker.sock挂载等关键词的操作 - 定期扫描镜像：用 Trivy、Clair 等工具检查基础镜像是否含已知逃逸漏洞（如 CVE-2025-31133）
