子UID空间通过内核user namespace将容器内UID/GID映射到宿主机非特权ID段，实现“容器内root即宿主机普通用户”的隔离。配置需三步联动：1. 在/etc/subuid与/etc/subgid中为租户预分配不重叠的65536 ID段（如tenant-a:100000:65536）；2. 在Docker daemon.json中启用{"userns-remap": "tenant-a"}并重启服务；3. 将挂载目录属主设为映射起始UID（如chown 100000:100000 /data/tenant-a）；4. 验证容器内id显示uid=0、宿主机ps显示UID=100000、文件属主为100000且特权操作被拒绝。
多租户环境下，Linux子UID空间（subuid/subgid）是实现容器级权限隔离的底层基石。它不依赖应用层逻辑，而是通过内核用户命名空间（user namespace）将容器内的UID/GID映射到宿主机上一段预分配的、非特权的ID范围，从而让容器“以为自己是root”，实则对宿主机资源只有普通用户权限。配置关键在于三步联动：定义ID段、启用映射、验证边界。
1. 预分配子UID/GID范围并写入系统文件
每个需隔离的租户（或系统用户）必须拥有独立、不重叠的UID/GID连续区间，最小建议65536个ID（覆盖完整POSIX范围）。以租户用户 tenant-a 为例：
- 编辑 /etc/subuid，添加一行：
tenant-a:100000:65536 - 编辑 /etc/subgid，添加对应行：
tenant-a:100000:65536 - 确保该用户在 /etc/passwd 中存在（如用
adduser --disabled-password tenant-a创建）
注意：不同租户的起始值（如100000、165536）必须严格错开，避免映射冲突；数值不可随意指定，需全局唯一且足够大，避开系统保留UID（0–999）。
2. 启用Docker或LXD的用户命名空间重映射
仅配置subuid/subgid不生效，必须在运行时引擎中显式启用映射机制：
-
Docker：修改 /etc/docker/daemon.json，加入：
{"userns-remap": "tenant-a"}
重启docker服务后，所有由tenant-a启动的容器自动启用该映射 -
LXD：对特定容器启用隔离：
lxc config set <container> security.idmap.isolated true
或为租户默认配置：lxc config set core.userns.mode auto
此时容器内UID 0（root）被映射为宿主机UID 100000，容器内新建文件在宿主机上属主显示为100000，而非真实root，无法修改/etc、加载内核模块等关键路径。
3. 挂载与数据卷的权限对齐
挂载宿主机目录（如 -v /data/tenant-a:/app）时，若宿主机目录属主不是映射后的UID（如100000），容器内进程将无权访问。解决方式有两种：
-
推荐：将宿主机目录属主设为映射起始UID：
chown 100000:100000 /data/tenant-a -
灵活方案：使用ACL授予映射UID组访问权：
setfacl -m u:100000:rwx /data/tenant-a
切勿将宿主机目录属主设为root并期望容器内root能直接写入——映射后权限已失效，这是最常见挂载失败原因。
4. 验证隔离是否真正生效
执行以下检查确认安全边界成立：
- 进入容器：
docker exec -it <container> id→ 显示uid=0(root) gid=0(root) - 查看宿主机对应进程：
ps -eo uid,comm | grep <container-pid>→ UID显示为100000 - 在容器内创建文件后，查宿主机：
ls -n /data/tenant-a→ 所有者应为100000 - 尝试在容器内执行
mount或ip link add→ 应报Operation not permitted
只要这四点全部满足，说明子UID空间已成功构筑容器与宿主机之间的权限隔离墙。
