🚀 导语：在 Docker 中，容器隔离并不等于权限天然安全。许多基础镜像默认以 root 身份启动进程，一旦应用漏洞、危险挂载或过度授权被利用，攻击影响可能进一步扩大。让业务进程以非 root 用户运行，并配合能力裁剪、只读文件系统和 Rootless 模式，是落实最小权限原则的重要手段。
一、先理解“容器内 root”的风险
容器内的 root 与宿主机 root 并非完全等同，但它通常拥有容器命名空间中的最高权限。如果容器同时使用特权模式、挂载 Docker Socket、共享宿主机目录，或者保留了不必要的 Linux Capability，攻击者就可能借助错误配置影响宿主机。因此，不能把“运行在容器里”当作唯一安全边界。🔐
权限降级的目标不是保证容器绝对安全，而是减少进程可执行的敏感操作，限制漏洞被利用后的影响范围。
二、在镜像构建阶段创建专用用户
推荐在 Dockerfile 中完成用户创建、文件授权和身份切换，而不是等到容器启动后再临时处理。一个常见流程是：先以 root 安装系统依赖，再创建固定 UID、GID 的业务用户，将应用文件交给该用户，最后通过 USER 指令切换身份。
示例思路：
FROM debian:stable-slim
RUN groupadd -g 10001 appgroup && useradd -u 10001 -g appgroup -M -s /usr/sbin/nologin appuser
WORKDIR /app
COPY --chown=appuser:appgroup . /app
USER 10001:10001
CMD ["./server"]
固定数字 UID、GID 有利于跨主机和编排平台保持一致，也能降低用户名解析差异带来的问题。COPY --chown 可以在复制文件时直接设置所有者，避免随后递归执行 chown，通常更利于构建层保持简洁。关于 USER、COPY 等指令的准确行为，可查阅 来源链接 官方参考。
三、正确处理目录与挂载权限
切换为非 root 用户后，最常见的问题是无法写入日志、缓存、上传或临时目录。解决方式不是恢复 root，而是明确应用真正需要写入的位置，并在镜像中预先创建目录、设置所有权。对于无状态服务，可将运行时写入集中到 /tmp 或指定数据目录。
- 只给必要目录写权限，不要对整个应用目录执行 chmod 777。
- 使用宿主机绑定挂载时，提前匹配宿主机目录与容器用户的 UID、GID。
- 使用命名卷时，可通过初始化步骤设置一次目录所有权。
- 不要让入口脚本每次启动都以 root 递归修改大型目录。
如果程序只需监听 HTTP 服务，优先使用 8080 等非特权端口，再由反向代理或端口映射对外提供 80、443 端口，避免仅为监听低位端口而让整个进程保持高权限。
四、在运行阶段增加强制约束
即使镜像已经声明 USER，部署时仍应设置运行约束，防止镜像更新或入口脚本变化导致权限回退。使用 docker run 时，可以通过 --user 10001:10001 指定身份，并结合 --read-only、--tmpfs /tmp、--cap-drop ALL 和 --security-opt no-new-privileges:true。
运行示例：
docker run --rm --user 10001:10001 --read-only --tmpfs /tmp --cap-drop ALL --security-opt no-new-privileges:true myapp:latest
能力应按需恢复，例如应用确实需要某项 Capability 时，再单独使用 --cap-add 添加。不要直接采用 --privileged，也不要为了方便把 /var/run/docker.sock 挂载到普通业务容器中，因为能够控制 Docker API 的进程通常可以创建高权限容器或访问宿主机资源。⚠️
五、区分非 root 容器与 Rootless Docker
USER 指令解决的是容器内业务进程身份问题，传统模式下 Docker 守护进程仍可能以 root 运行。Rootless Docker 则让守护进程和容器均运行在普通用户的用户命名空间内，从而进一步减少守护进程被攻击后的宿主机风险。其工作原理、安装前提及 UID/GID 映射方式可参考 Rootless 模式官方文档。
需要注意的是，把普通用户加入 docker 用户组并不等于 Rootless。该用户虽然调用命令时不再需要 sudo，但仍可通过拥有高权限的 Docker 守护进程执行敏感操作。生产环境应结合网络、存储驱动、端口绑定和运维方式评估 Rootless 模式的适用性。
六、验证权限降级是否真正生效
- 执行 docker inspect，检查镜像或容器配置中的 User 字段是否为空。
- 进入容器运行 id 和 ps，确认主进程不是 UID 0。
- 尝试写入应用目录及系统目录，验证只允许预期路径写入。
- 检查 CapEff 或使用能力分析工具，确认未保留无关 Capability。
- 扫描 Dockerfile 与部署配置，阻止 privileged、危险挂载和权限回退进入生产环境。
容易忽略的细节
不要在切换 USER 后继续安装软件；不要让应用依赖修改 /etc、/usr 等系统目录；不要把密钥复制进镜像后仅依靠文件权限保护；不要假设第三方镜像已经配置非 root 用户。对于必须短暂提权的初始化操作，最好拆分为独立任务，完成后让常驻服务始终以低权限身份运行。
总结
✅ Docker 权限治理应贯穿构建、发布和运行全过程：镜像内创建固定 UID、GID 的专用用户，精确设置文件所有权；运行时强制指定用户，删除无关 Capability，启用 no-new-privileges 和只读文件系统；宿主机侧则避免暴露 Docker Socket，并按场景评估 Rootless 模式。非 root 运行不是单一开关，而是一组相互配合的最小权限措施。只有同时控制身份、文件、能力、挂载和守护进程权限，才能建立更稳健的容器安全边界。
