启用User Namespace可将容器内root映射为宿主机非特权UID（如100000），从根本上限制逃逸危害；需配置daemon.json启用userns-remap、调整挂载目录属主为映射UID、避免使用--privileged，并与镜像内非root用户协同实现纵深防御。
在 Docker 中启用 User Namespace（用户命名空间）能从根本上削弱容器逃逸后对宿主机的威胁——它不禁止容器内用 root，而是让这个 root 在宿主机上变成一个普通数字（比如 100000），无法访问真实 root 资源。关键在于配置映射规则并处理好文件权限和兼容性问题。
全局启用 user namespace remapping
这是最基础也最关键的一步。Docker 默认关闭该功能，需手动开启：
- 编辑 /etc/docker/daemon.json，加入：
{"userns-remap": "default"} - 保存后执行 sudo systemctl restart docker
- Docker 会自动创建系统用户 dockremap，并在 /etc/subuid 和 /etc/subgid 中分配一段子 ID（如 dockremap:100000:65536），表示容器内 UID 0 → 宿主机 UID 100000，UID 1 → 100001，依此类推
适配挂载卷的文件属主
UserNS 启用后，容器内进程写入绑定挂载目录时，生成的文件在宿主机上会显示为映射后的 UID/GID（例如 100000:100000），而非你当前登录用户的 ID。若不提前调整，应用可能因无权限读写而失败：
- 对宿主机上的挂载目录，运行：
sudo chown -R 100000:100000 /path/on/host - 如果使用自定义 remap 用户（如 "userns-remap": "myuser"），则改用对应分配的起始 UID（如 200000）
- 也可在启动容器时用 --user 显式指定映射后 UID，但需确保与 subuid 范围一致
避免与特权模式冲突
UserNS 和 --privileged 是互斥的。一旦启用 userns-remap，带 --privileged 参数的容器将无法启动，报错提示“userns-remap is enabled”。这是设计使然：
- 特权模式会绕过大量内核安全检查，与 UserNS 的隔离目标相悖
- 如确实需要某些能力（如加载内核模块、修改网络栈），应改用细粒度的 --cap-add 或 seccomp profile，而不是全开特权
- 多数生产应用完全不需要 --privileged，禁用它本身就是一项重要加固
配合镜像内非 root 用户使用效果更佳
UserNS 是宿主机层面的隔离，而镜像中用 USER 指令切换到非 root 用户是应用层降权。两者叠加可形成纵深防御：
- Dockerfile 中创建 UID 1001 的用户：
RUN adduser -u 1001 -D appuser && chown -R appuser /app
USER appuser - 该用户在容器内是普通用户；UserNS 还会把它映射成宿主机上 100000+ 范围内的某个 UID，双重限制
- 相比只用 USER 指令（容器内仍是 root 启动再降权），这种组合更彻底地切断了初始高权限路径
