非 root 运行需构建阶段创建固定 uid 用户、精准设置文件归属、严格 user 指令顺序，并运行后验证进程身份与权限边界，缺一不可。
让应用在 Docker 容器里以非 root 用户运行，不是加个 USER 就算完成，而是从构建起点就切断默认高权路径。关键在于用户存在、权限匹配、运行验证三者闭环，缺一不可。
创建确定 UID 的专用用户
容器不读宿主机 /etc/passwd，必须在构建阶段显式创建。推荐固定 UID ≥ 1001（避开系统用户范围），不配 shell 和 home 目录，减少攻击面：
- Debian/Ubuntu 镜像：
RUN adduser --disabled-password --gecos '' --uid 1001 appuser - Alpine/CentOS 镜像：
RUN addgroup -g 1001 -f appgroup && adduser -S -u 1001 -G appgroup appuser - 若基础镜像已带非 root 用户（如
node:alpine的node），优先复用，但需确认其 UID/GID 与挂载目录一致
精准设置文件归属，避免启动失败
COPY 或 ADD 后，应用目录、日志路径、临时目录等必须对目标 UID 可读写。错误做法是递归 chown 整个 /；正确做法是聚焦最小必要集：
- 推荐直接在 COPY 中控制归属：
COPY --chown=1001:1001 . /app - 配套提前建好工作目录并赋权：
RUN mkdir -p /app /var/log/myapp /tmp && chown -R 1001:1001 /app /var/log/myapp /tmp - 多阶段构建中，最终镜像只保留二进制、配置、启动脚本，剔除源码、.git、构建缓存等无关内容
USER 指令位置必须严格守序
USER 只影响其后的指令（CMD、ENTRYPOINT、后续 RUN），不会回溯修改之前文件的所有者。顺序错一步，轻则启动报错，重则权限失效：
- ✅ 正确示例：先安装依赖、再复制并设权、最后切换用户
- ❌ 错误示例：
USER appuser放在RUN apt-get install前，导致安装失败 - 多阶段构建中，仅最终运行阶段需设
USER；构建阶段仍可用 root 安装依赖或编译
运行后必须手动验证是否真生效
不能只看 Dockerfile 写了 USER 就认为加固完成。启动容器后需进入确认实际进程身份和权限边界：
- 检查进程 UID：
docker exec -it ps aux | grep your-app，USER 列应为1001或用户名 - 尝试以 root 进入：
docker exec -u 0 -it sh，应被拒绝（除非启用 user namespace remap） - 测试越权操作：
docker exec -u 1001 touch /etc/test，应返回Permission denied
非 root 是安全基线，不是终点。生产环境建议叠加 --cap-drop=ALL --cap-add=NET_BIND_SERVICE、--read-only、--security-opt no-new-privileges，Kubernetes 中还可配合 securityContext.runAsNonRoot: true 强制兜底。
