容器带来了快速交付与环境一致性，但它并不是传统虚拟机。Docker 容器与宿主机共享 Linux 内核，一旦应用漏洞、危险配置和内核缺陷形成攻击链，攻击者就可能突破命名空间与权限边界，控制宿主机或横向访问其他容器。🔐 因此，容器逃逸治理不能只依赖镜像扫描，而应覆盖配置检查、运行时检测、主机加固和事件响应。
一、什么是 Docker 容器逃逸
容器逃逸是指攻击者已经在容器内获得一定执行能力，随后利用运行时漏洞、内核漏洞或错误配置，访问原本不应触达的宿主机资源。成功逃逸后，攻击者可能读取宿主机文件、操作其他容器、窃取凭据，甚至通过 Docker 守护进程创建高权限容器。
需要注意的是，“容器内使用 root 用户”不等于已经逃逸，但会显著放大风险。容器中的 root 若同时拥有危险 Capability、宿主机目录挂载或 Docker Socket 访问权限，就可能将一次普通的应用入侵升级为宿主机失陷。
二、重点排查高风险配置
1. 特权模式与危险权限
首先检查是否存在以 --privileged 运行的容器。特权模式会明显削弱设备、Capability 和安全配置文件等隔离措施，普通业务通常没有启用它的必要。还应重点关注 SYS_ADMIN、SYS_MODULE、SYS_PTRACE 等高风险 Capability，以及使用 seccomp=unconfined、关闭 AppArmor 或 SELinux 约束的情况。
管理员可执行 docker inspect 容器名称，核对 Privileged、CapAdd、SecurityOpt、PidMode、IpcMode 和 User 等字段；也可通过 docker ps --no-trunc 建立当前容器清单。若发现 host PID、host IPC 或特权模式，应结合业务用途逐项确认，而不是直接视为正常配置。
2. 敏感目录与 Docker Socket 挂载
检查 Mounts 和 Binds 中是否出现宿主机根目录、/etc、/proc、/sys、/dev、SSH 目录以及 /var/run/docker.sock。Docker Socket 相当于守护进程的控制入口，获得访问权限的容器通常可以创建新容器、挂载宿主机目录或读取其他工作负载信息。
生产环境不应为了方便管理而把 Socket 直接交给普通业务容器。确需远程管理 Docker 时，应优先采用 SSH 或经过双向认证的 TLS，并严格限制可访问账户，具体方式可参考 Docker 守护进程访问保护文档。
3. 镜像、运行时与宿主机补丁
逃逸漏洞往往涉及 Linux 内核、runc、containerd 或 Docker Engine，因此只更新应用镜像并不够。应定期盘点版本，订阅供应商安全公告，及时修复已确认影响当前环境的漏洞。镜像侧则要采用可信、精简的基础镜像，在构建阶段执行漏洞扫描，并删除编译器、调试器和多余的软件包。🛡️
三、建立运行时逃逸检测
静态检查只能发现“可能发生什么”，运行时监控用于识别“正在发生什么”。建议采集 Docker 事件、系统审计日志、进程执行、文件访问和网络连接信息，并重点关注以下信号：
- 容器内突然执行 nsenter、unshare、mount、insmod、modprobe 等敏感工具；
- 容器进程尝试访问宿主机设备、内核接口、运行时 Socket 或异常的 procfs 路径；
- 业务容器创建新容器、修改守护进程配置或访问其他容器命名空间；
- 出现反向连接、异常端口监听、挖矿进程或不符合基线的高 CPU 行为；
- 容器启动参数被改为特权模式，或在非变更窗口新增宿主机目录挂载。
可使用 Falco 等运行时安全工具监控系统调用与容器行为，但规则不宜照搬后立即全量告警。更实用的方法是先建立业务基线，再根据容器名称、镜像、命名空间和维护窗口设置例外，最终将高置信度事件发送到日志平台或告警系统。检测规则应覆盖“敏感操作加容器身份加异常上下文”的组合，减少只靠单一进程名产生的误报。
四、可落地的防护策略
- 落实最小权限：默认删除全部不必要的 Capability，再按应用需求逐项添加；禁止普通服务使用特权模式和宿主机命名空间。
- 限制 root：在镜像中设置非 root 用户，结合 user namespace 或 Rootless 模式降低容器 UID 0 对宿主机的影响。Rootless 模式的工作原理与前置条件可查看 Docker Rootless 官方文档。
- 保留安全配置：不要随意关闭 Docker 默认 seccomp 策略；对高敏业务可进一步定制允许的系统调用。相关配置方式可参考 Docker seccomp 官方文档。
- 收紧文件系统：尽量启用只读根文件系统，仅为必要目录提供可写卷，并使用 no-new-privileges 阻止进程通过 setuid 或 setgid 获取额外权限。
- 保护管理面：严格控制 docker 用户组成员，避免将 Docker API 暴露在未认证网络中，对管理操作保留审计记录。
- 实施网络隔离：按业务用途划分网络，限制容器访问宿主机管理端口、云元数据服务和非必要的内部系统。
- 持续验证：在 CI 阶段检查 Dockerfile 与 Compose 配置，在部署前拦截 privileged、Socket 挂载、危险 Capability 和不可信镜像。
五、发现疑似逃逸后的处置
处理原则是先控制影响范围，再保留证据，最后修复根因，避免为了“快速恢复”直接删除全部现场。
发现异常后，应立即隔离相关容器和宿主机网络，暂停可疑凭据与自动部署任务；随后保存容器配置、镜像摘要、Docker 事件、进程树、网络连接与系统日志。若存在宿主机失陷迹象，不应只重启容器，而要轮换宿主机、仓库、CI/CD 及业务密钥，并在可信环境中重建节点。🚨
复盘时应明确最初入口、权限升级路径、受影响资产和检测盲区，将修复措施转化为镜像策略、部署准入规则与运行时告警。对同批镜像和同配置节点进行横向排查，才能避免遗漏相同风险。
总结
Docker 容器逃逸通常不是单点问题，而是应用漏洞、过度授权、敏感挂载和监控缺失共同作用的结果。有效防护应坚持“默认不特权、默认最小权限、默认不暴露管理面、默认保留检测能力”。通过配置审计、补丁治理、非 root 运行、seccomp 约束、运行时监控与规范化响应，可以显著缩小攻击面，并把潜在逃逸行为更早地阻断在容器边界内。✅
