如何借助限制账号在特定容器环境内的权限防止逃逸指南

必须用非root用户运行容器，这是最基础最关键的安全实践：默认root运行等于将系统钥匙交给攻击者，应在Dockerfile构建阶段就创建低权限用户（如USER 1001）并切换，配合--chown确保文件属主匹配，杜绝权限滥用风险。

核心是让容器进程“有事干、没权干坏事”——不给 root，不给多余能力，不给宿主机通路。权限限制不是加一道锁，而是层层设防，从用户身份、系统调用、挂载行为到命名空间全部收紧。

用非 root 用户运行容器

这是最基础也最关键的一步。默认 root 运行等于把钥匙直接交给攻击者。必须在镜像构建阶段就切换用户，不能靠运行时临时指定。

• Dockerfile 中提前创建低权限用户（推荐数值 UID，如 USER 1001），避免与宿主机用户 ID 冲突
• 多阶段构建中，构建阶段可用 root，但最终镜像必须 COPY 文件后立即 USER 切换，且确保文件属主已设为该用户（用 --chown=1001:1001）
• 若挂载宿主机目录（如日志或配置卷），需提前在宿主机上 chown 1001:1001 对应路径，否则容器内无写权限

丢弃所有 capabilities，再按需添加

Linux capabilities 是比 root 更细的权限切片。Docker 默认赋予二十多项，其中几个就是逃逸入口。宁可少加，不可多给。

• 启动容器时强制 --cap-drop=ALL，清空所有能力
• 只加真正需要的，例如绑定 80 端口才加 --cap-add=NET_BIND_SERVICE
• 绝对禁用：CAP_SYS_ADMIN（等同于 root 权限）、CAP_SYS_PTRACE（可调试宿主机进程）、CAP_SYS_MODULE（可加载恶意内核模块）

切断逃逸常用路径：挂载与命名空间

很多逃逸不是靠漏洞，而是靠配置放行了本不该暴露的通道。关键是要主动关闭，而不是等出事再堵。

• 禁止挂载 docker.sock——这是最常见逃逸跳板，除非明确需要管理 Docker 引擎，否则一律不挂
• 宿主机目录挂载一律加 :ro（只读），写入需求改用 emptyDir 或专用 volume
• 禁用 --network=host、--pid=host、--ipc=host，它们会共享对应命名空间，破坏隔离边界
• 避免挂载 /proc、/sys、/dev 等敏感路径，尤其不要递归挂载根目录（-v /:/host）

启用 seccomp 和只读文件系统

这是最后一道防线：即使前几层被绕过，也能拦住危险系统调用；即使攻击者拿到 shell，也没法改写关键文件。

• 启动容器时加上 --security-opt seccomp=unconfined 是危险操作；应使用 Docker 默认 profile（--security-opt seccomp=runtime/default）或定制精简版
• 对静态服务（如 Nginx、API 服务）启用 --read-only，根文件系统设为只读，运行时写操作只能落在 /tmp 或显式挂载的 volume 上
• 配合 readOnlyRootFilesystem: true（K8s 中）和 allowPrivilegeEscalation: false，双重锁定提权路径