最直接有效的加固方式是让应用以非root用户运行：在Dockerfile中创建UID≥1001的专用用户，提前chown必要路径，启动后验证进程UID及权限限制。

在 Docker 镜像中默认以 root 用户运行进程存在明显安全风险，攻击者一旦突破应用层，即可获得容器内最高权限，进而可能横向渗透或逃逸。最直接有效的加固方式是：让应用进程在镜像内以非 root 用户身份运行，并确保该用户拥有最小必要权限。

创建专用非 root 用户并设置 UID

Docker 容器不依赖系统用户数据库，因此需在构建阶段显式创建用户。推荐使用大于 1000 的固定 UID（避免与宿主机用户冲突），不分配登录 shell 和 home 目录（除非应用必需）：

• 在 Dockerfile 中添加：RUN addgroup -g 1001 -f appgroup && adduser -S appuser -u 1001
• 若需兼容某些只认 numeric UID 的工具（如 gosu），可跳过用户名，直接用 adduser -S -u 1001 -G appgroup appuser
• 避免使用 USER appuser:appgroup 后再 chown 数据目录——应在 USER 指令前完成权限变更

调整文件与目录权限适配非 root 用户

应用所需文件（配置、日志路径、临时目录等）必须对目标 UID 可读写。常见错误是 COPY 后未改权限，导致启动失败：

• COPY 文件后立即执行：RUN chown -R 1001:1001 /app /var/log/myapp /tmp
• 若使用多阶段构建，最终镜像中仅保留运行时必需的文件，避免残留构建用户或敏感路径
• 禁止将整个 / 或 /usr 递归 chown ——只需最小集，如配置目录、日志挂载点、缓存路径

验证非 root 运行与权限边界

构建完成后必须验证实际运行效果，不能仅依赖 Dockerfile 逻辑：

• 启动容器后执行：docker exec -it ps aux | grep your-app，确认 USER 列显示为 1001 或 appuser
• 尝试在容器内切换用户：docker exec -u 0 -it sh 应被拒绝（若启用 --userns-remap 或 rootless Docker 则行为不同）
• 检查关键路径是否不可写：docker exec -u 1001 touch /etc/test 应返回 Permission denied

补充增强措施（非必需但推荐）

非 root 用户只是基础，结合其他机制可进一步收窄攻击面：

• 运行时指定用户：docker run --user 1001:1001 ...，覆盖镜像内 USER 指令，适合多租户环境
• 禁用 capabilities：--cap-drop=ALL，再按需添加（如 --cap-add=NET_BIND_SERVICE 绑定 80 端口）
• 挂载卷时显式指定 uid/gid：-v $(pwd)/logs:/var/log/myapp:Z（SELinux）或使用 chown 1001:1001 logs/ 预处理宿主机目录