在容器化实践中，许多应用只关注“能否启动”，却忽略了进程以什么身份运行。若容器长期使用 root 用户，一旦应用存在命令执行、文件上传或依赖漏洞，攻击者可能获得更大的容器内权限；当容器同时挂载宿主机目录、Docker Socket 或敏感配置时，风险还会进一步扩大。🔐 因此，让业务进程以非 root 用户运行，并配合最小文件权限、只读挂载和能力限制，是 Docker 安全加固的重要基础。
为什么不建议业务进程使用 root
容器内的 root 与宿主机 root 并不完全等同，但 UID 仍为 0，能够修改容器可写层中的大量文件、安装工具或调整运行环境。如果容器配置了高权限模式，或者暴露了敏感挂载点，root 进程带来的影响范围会明显增加。非 root 运行不能替代漏洞修复和运行时隔离，却能减少不必要的权限，为攻击路径增加限制。
需要注意的是，镜像构建阶段使用 root 安装软件并不等于运行阶段必须使用 root。常见做法是先由 root 完成依赖安装、目录创建和文件复制，最后通过 Dockerfile 的 USER 指令切换到专用账户。USER 会设置后续构建指令以及容器默认运行进程所使用的用户和组，具体规则可参考 Dockerfile USER 官方说明。
在镜像中创建专用用户
建议为每个应用创建没有登录用途的专用用户，并明确指定 UID 和 GID。固定数值有利于不同环境保持一致，也便于宿主机目录、共享存储和编排平台进行权限匹配。不要让业务账户加入 sudo、root 或其他不必要的高权限组。
FROM debian:stable-slim
RUN groupadd -g 10001 appgroup && useradd -r -u 10001 -g appgroup -d /app appuser
WORKDIR /app
COPY --chown=appuser:appgroup . /app
USER 10001:10001
CMD ["./app"]
这里使用 COPY --chown 在复制文件时直接设置所有者，避免先复制再递归执行 chown，从而让构建过程更简洁。切换用户之前，还应提前创建日志、缓存、上传文件等运行时目录，并只把必要目录交给应用账户管理。镜像中的配置文件和程序文件通常只需读取权限，不应全部设为可写。
正确处理 UID、GID 与挂载目录
非 root 改造中最常见的问题是“Permission denied”。Linux 文件权限主要依据数字 UID 和 GID 判断，而不是用户名。即使容器内外都存在名为 appuser 的账户，只要 UID 不一致，绑定挂载目录仍可能无法写入。反过来，若容器以 root 写入宿主机目录，还可能留下普通宿主机用户无法删除的 root 所属文件。
开发环境可以将宿主机用户的 UID、GID作为构建参数传入镜像，或在启动时使用 --user 指定运行身份。例如执行 docker run --user 1000:1000 image，可以临时覆盖镜像中的默认用户。不过，运行时覆盖用户可能导致其在容器内没有 HOME 目录或 passwd 记录，因此生产镜像更适合预先创建固定账户。
使用绑定挂载前，应在宿主机上创建目标目录，并将所有权调整为容器实际使用的 UID、GID。不要为了快速解决问题直接执行 chmod 777，这会让所有用户获得写权限，掩盖真正的身份映射问题。绑定挂载默认可能允许容器修改宿主机文件；只需读取配置或证书时，应添加 ro 或 readonly，相关行为可参考 Docker Bind Mount 官方文档。
进一步收紧容器权限
仅设置 USER 还不够，建议继续遵循最小权限原则。应用无需写入根文件系统时，可以使用 --read-only，并通过单独的 volume 或 tmpfs 提供必要的临时写入位置。对于 Linux capabilities，可先使用 --cap-drop=ALL 移除默认能力，再按实际需求逐项添加，而不是直接启用 --privileged。🛡️
- 限制写入范围：仅让日志、缓存、上传目录可写，其余路径保持只读。
- 保护敏感挂载：配置、证书和静态资源优先采用只读挂载。
- 禁止权限提升：可使用 no-new-privileges，阻止进程通过 setuid 等机制获得额外权限。
- 避免危险接口：不要随意把 /var/run/docker.sock 挂载到普通业务容器。
- 控制临时文件：明确 TMPDIR，并为临时目录设置合理容量和访问权限。
排查非 root 启动失败
遇到权限错误时，不要立即回退到 root。可以先检查运行身份、文件所有者、目录权限和挂载方式。容器内可执行 id 查看 UID、GID及附加组，使用 ls -ld 检查目标目录，再通过 stat 查看具体文件的数字所有权。若镜像内权限正确，但挂载后发生变化，应重点检查宿主机目录，因为绑定挂载会遮蔽镜像原目录中的内容和权限。
- 确认最终镜像是否已经声明 USER，启动参数是否又覆盖了用户。
- 确认工作目录、配置目录和可写目录是否真实存在。
- 比较容器进程 UID、GID与挂载目录的数字所有者。
- 检查入口脚本是否尝试安装软件、修改系统目录或监听受限制端口。
- 删除不必要的写权限和能力后，重新执行功能及健康检查。
总结
Docker 使用非 root 用户运行的核心不是简单添加一行 USER，而是同时处理账户创建、UID/GID、文件所有权、挂载目录和运行时能力。✅ 推荐在镜像中创建固定的专用账户，使用 COPY --chown 准备应用文件，只开放必要的写入目录，并结合只读文件系统、只读挂载、capabilities 控制及 no-new-privileges。遇到权限问题时，应从数字身份和目录所有权入手排查，而不是依赖 chmod 777 或重新使用 root。这样既能保持应用稳定运行，也能建立更清晰、可审计的容器权限边界。
