最有效、成本最低的Docker安全加固是用非root用户运行容器，核心三步：先创建固定UID（如1001）的专用用户，再用COPY --chown同步设置文件归属，最后在所有root操作完成后执行USER指令切换，顺序错误会导致启动失败或权限异常。
直接用非 root 用户运行容器，是 Docker 安全加固最有效、成本最低的一步。关键不是“能不能切”，而是“怎么切得稳、切得对”。
先创建用户，再切换身份
USER 指令本身不创建用户，它只是“切换”——目标用户必须已在镜像中存在。跳过创建步骤直接写 USER appuser 会导致容器启动失败。
- 推荐用
adduser -u 1001 -D appuser创建无家目录、不可登录的专用用户（-D避免生成 shell 配置文件） - 配合
addgroup -g 1001 appgroup建组，再用useradd -u 1001 -g appgroup -G appgroup appuser确保 UID/GID 明确且可复现 - 避免使用
useradd -m创建家目录——多数服务不需要，反而增加攻击面和镜像体积
文件权限要同步匹配
用户切换后，如果应用文件仍属 root，进程会因无读/执行权限而崩溃。不能只改 USER，不改文件归属。
- 复制代码时用
COPY --chown=1001:1001 ./src /app，一步完成内容拷贝 + 权限赋予 - 若需多步 RUN 操作（如安装依赖、编译），建议在 USER 切换前就用
RUN chown -R 1001:1001 /app统一归属 - 特别注意：挂载卷（volume）或 bind mount 的宿主机路径，其权限需与容器内 UID 一致，否则写入失败
用数字 UID 替代用户名更可靠
用户名在不同基础镜像中可能不存在（比如 alpine 和 ubuntu 的默认用户列表不同），但 UID 是通用的。
- 写成
USER 1001或USER 1001:1001比USER appuser更稳定，尤其在 distroless 或精简镜像中 - 固定 UID（如 1001）便于在 Kubernetes SecurityContext 中统一配置
runAsUser，也方便宿主机映射权限 - 避开系统保留 UID 范围（0–999），选 1000+ 的普通用户区间，符合最小权限原则
别让 CMD/ENTRYPOINT 无意绕过 USER
USER 设置只影响后续指令的默认执行上下文，但某些写法会隐式提升权限。
- 避免
CMD ["sh", "-c", "exec myapp"]这类 shell 封装——sh 默认以当前 USER 启动，但 exec 不改变用户，风险可控；真正危险的是CMD ["sudo", "./app"] - ENTRYPOINT 若为 shell 形式（如
ENTRYPOINT sh -c '...'），会继承 USER；若为 exec 形式（ENTRYPOINT ["./start.sh"]），则严格按 USER 执行 - 验证方式：构建后运行
docker run --rm your-image id，输出应为uid=1001(...) gid=1001(...)
