让容器里的 root 不再是真 root
启用用户命名空间映射后，容器内的 root 会被映射成宿主机上的一个非特权用户：容器里照样以 root 运行，但一旦越出容器边界，在宿主上只是普通用户的权限。这是守护进程级配置，改动影响整机容器。代价集中在文件属主关系上——卷与绑定目录里的文件在宿主侧会显示成映射后的高 UID，已有数据的目录需要重新处理权限。
基本信息
| 配置位置 | daemon.json 的 userns-remap 字段 |
|---|---|
| 配置示例 | "userns-remap": "default" |
| 效果 | 容器内 root 映射为宿主非特权用户 |
| 核对方式 | docker info 的 SecurityOptions 与容器内 id 命令 |
典型使用场景
- 多租户机器加固：降低容器逃逸后的实际权限
- 合规要求落地：对容器内 root 的等效权限做收敛
- 测试环境验证：先在非生产机器上确认业务不受影响
- 数据目录规划：提前确定映射后的属主范围再决定是否需要调整权限
- 安全评审：把是否启用该能力作为基线检查项之一
配置与验证
配置与验证
{
"userns-remap": "default"
}
# 重载守护进程后核对生效情况
# docker info -f '{{json .SecurityOptions}}'
# docker run --rm alpine id
# docker run --rm -v /tmp/userns-test:/data alpine sh -c 'touch /data/f'; ls -ln /tmp/userns-test启用前后的差别
| 对象 | 启用前 | 启用后 |
|---|---|---|
| 容器内 root | 与宿主 root 等效 | 映射为宿主上的非特权用户 |
| 卷内文件属主 | 与容器内用户一致 | 宿主侧显示为映射后的高 UID |
| 绑定目录 | 按容器用户匹配权限 | 需按映射后的 UID 重新调整 |
| 已存在的容器 | 保持原样 | 需要重建后才有新映射 |
切换是整机级操作：已有容器与卷不会自动迁移，启用前要规划停机窗口以及数据属主的处理方式。
部分需要宿主机权限的功能与该能力存在兼容限制，逐项验证业务比整体切换更稳妥。
判断是否启用成功，除了看 docker info 的安全选项，还可以在容器里执行 id：容器内仍是 root，但宿主侧对应的文件属主会落在高 UID 区间，这两处对照一致才算配置到位。