Docker通过User Namespace将容器内root映射为宿主机普通UID（如100000），需配置daemon.json启用userns-remap，调整挂载目录属主，并配合Dockerfile中USER指令实现双重降权。
在 Docker 中用 User Namespace 实现容器内 root 用户降权，核心不是让容器“不用 root”，而是让这个 root 在宿主机上变成一个普通数字——比如 UID 100000。它在容器里仍是 root（uid=0），但在宿主机上没有 root 权限，无法修改关键系统文件、加载模块或接管其他进程。
配置 Docker 守护进程启用映射
这是整个机制的前提，必须全局开启：
- 编辑 /etc/docker/daemon.json，加入：
{"userns-remap": "default"} - 保存后执行 sudo systemctl restart docker（注意：reload 不生效，必须完整重启）
- Docker 会自动创建系统用户 dockremap，并在 /etc/subuid 和 /etc/subgid 中分配一段子 ID 范围，例如：
dockremap:100000:65536
表示容器内 uid 0 → 宿主机 uid 100000，uid 1 → 100001，依此类推 - 若自动创建失败（如最小化系统），可手动添加：
sudo useradd -r -u 100000 dockremapecho 'dockremap:100000:65536' | sudo tee -a /etc/subuid /etc/subgid
适配挂载目录的属主权限
User Namespace 启用后，容器内进程对宿主机文件的访问，实际使用的是映射后的 UID/GID。如果挂载目录属主没对齐，就会出现 Permission denied：
- 查映射起始 UID：
awk -F':' '/dockremap/ {print $2}' /etc/subuid（通常为 100000） - 将绑定挂载的宿主机目录属主设为该 UID：
sudo chown -R 100000:100000 /host/data - 即使镜像中用了
USER 1001，该 UID 也会被整体偏移成 101001，不影响应用逻辑，但属主仍需按映射基址调整
避免与特权操作冲突
User Namespace 的设计目标是限制权限，因此天然排斥高危能力：
-
--privileged会被直接拒绝，启动时报错 “userns-remap is enabled” -
--cap-add=CAP_SYS_ADMIN等接近 root 的 capability 基本无效，不建议添加 - 若需调用 Docker API（如挂载
/var/run/docker.sock），需额外确保容器内 GID 映射到宿主机 docker 组的 GID，否则连接失败
配合镜像内 USER 指令做双重降权
User Namespace 是运行时隔离，USER 指令是构建时加固，两者叠加效果更扎实：
- 在 Dockerfile 中显式创建非 root 用户并切换：
RUN addgroup -g 1001 appgroup && adduser -u 1001 -G appgroup -D appuserUSER appuser - 这样容器内默认以 UID 1001 运行；User Namespace 再将其映射为宿主机上的 101001，既脱离 root 上下文，又受命名空间限制
- 相比只用 USER 指令，这种组合能防住更多逃逸路径，比如某些利用内核漏洞提权到容器 root 后的横向操作
