USER指令不能预防逃逸，但能限制逃逸后的危害范围；需显式创建专属非特权用户（如addgroup和useradd），配套--chown或chown调整文件权限，并在构建末尾唯一设置USER，配合运行时策略禁用root覆盖。

直接用 USER 指令切换普通用户，本身不能“预防”逃逸漏洞，但它能显著限制逃逸成功后的危害范围——这是防御纵深里的关键一环。核心逻辑是：即使攻击者突破应用层、拿到容器 shell，若进程本就以低权限用户运行，他就无法轻易修改系统文件、挂载敏感路径或调用高危 syscall，从而阻断多数逃逸链。

创建专用非特权用户，别用 nobody 或 1001 这类通用 ID

很多团队图省事写 USER nobody 或 USER 1001，但这些用户往往属于 root 组、有残留权限，甚至在某些基础镜像里根本没被正确初始化。真正安全的做法是显式创建专属用户：

• 用 addgroup -g 1001 appgroup 创建独立组
• 再用 useradd -u 1001 -g appgroup -m -s /bin/sh -d /home/appuser appuser 创建用户（-m 确保 home 目录，-s 指定 shell 避免登录失败）
• 避免复用系统预置用户（如 daemon、www-data），防止因历史配置引入意外权限

文件归属必须同步调整，否则应用启动就失败

USER 只切换执行身份，不自动改文件权限。如果应用代码、配置、日志目录仍属 root，切换后会因“Permission denied”直接退出——这时 Docker 可能静默回退或报错中断，反而暴露问题。务必配套处理：

• 复制文件时用 COPY --chown=appuser:appgroup ./src/ /app/
• 或构建后期加 RUN chown -R appuser:appgroup /app
• 特别注意：WORKDIR、/tmp、/var/log 等运行时写入目录也要提前 chown

运行阶段彻底剥离 root 权限，构建阶段保留即可

构建时需要 root 安装依赖、解压包、设置环境；但运行时完全不需要。最佳节奏是：

• 所有 RUN 指令（安装、编译、配置）保持 root 上下文
• COPY 和 chown 放在 USER 切换前最后一刻
• USER appuser 放在 Dockerfile 尾部，且只出现一次
• 确保 CMD 或 ENTRYPOINT 启动的进程直接受该用户控制，不通过 sudo/shell wrapper 提权

配合运行时约束，堵住参数覆盖漏洞

镜像里设了 USER，不代表运行时就安全——用户可用 docker run --user root 强制覆盖。生产环境必须配合策略拦截：

• Kubernetes 中启用 PodSecurityPolicy 或 Pod Security Admission，禁止 runAsUser: 0
• 在 CI/CD 流水线中用 Trivy 或 dockle 扫描镜像，告警未设 USER 或 USER root 的镜像
• 容器运行时（如 containerd）配置默认 user namespace 映射，让容器内 UID 0 不等于宿主机 root