用户命名空间使容器内root在宿主机映射为无特权高UID，如100000，无法访问关键系统目录或越权操作；需配合只读根文件系统、合理挂载权限及最小化能力授予，并通过docker info和ps命令验证生效。
用户命名空间让容器 root “有名无权”
用户命名空间（User Namespace）不取消容器内 UID 0 的 root 身份，而是做一层 ID 映射：容器里显示为 root（UID 0），实际在宿主机上对应一个普通、无特权的高数字 UID（比如 100000）。这个 UID 在宿主机上对 /etc、/var、/root 等关键目录默认没有读写权限，连创建文件都可能被拒绝。攻击者即使在容器内提权到 root，进程在宿主机视角仍是非特权用户，无法修改系统配置、加载内核模块或操作其他用户的进程。
映射机制切断权限继承链
启用后，Docker 会依据 /etc/subuid 和 /etc/subgid 中为运行用户（如 dockremap）分配的子 ID 段（例如 100000:65536），将容器内 UID 0–65535 映射到宿主机 UID 100000–165535。这意味着：
- 容器 A 和容器 B 的 root 都映射到宿主机 UID 100000，彼此隔离，互不可见对方的文件
- 宿主机上真实 UID 0（root）和 1–99999 的系统用户完全不受该映射影响，保持原有权限边界
- 容器内进程若尝试通过 mount、pivot_root 或 setns 等系统调用逃逸，因缺少 CAP_SYS_ADMIN 等能力且宿主机 UID 无权限，操作直接失败
配合挂载与文件系统加固效果
仅靠 UID 映射还不够。用户命名空间必须和以下措施协同使用，才能堵住常见越权路径：
- --read-only：根文件系统设为只读，防止恶意覆盖二进制或配置文件
- -v 挂载时显式指定 UID/GID：宿主机目录需提前 chown 到映射范围内的 UID（如 chown -R 100000:100000 /data），否则容器内应用无法写入
- 禁用 --privileged 和盲目加 cap-add：CAP_SYS_ADMIN、CAP_DAC_OVERRIDE 等能力会绕过命名空间限制，应按需最小化授予
验证是否真正生效
启动容器后可快速确认防护是否到位：
- 执行 docker info | grep "userns"，看到
Userns Default Mapping或类似字段表示已启用 - 进入容器运行 id，显示 uid=0(root)；再在宿主机查该容器进程：ps -eo pid,user,comm | grep containerd-shim，对应 UID 应为 100000 类似值，而非 0
- 尝试在容器内 touch /host/etc/test（宿主机 /etc 映射进来），应返回
Permission denied
