命名空间是容器隔离的骨架而非权限开关，真正权限控制需结合用户命名空间映射、能力集裁剪和挂载限制三者协同实现。
Linux 容器的权限隔离，核心在于命名空间（Namespace）机制——它不是简单地“关上门”，而是为每个容器构造一套独立的系统视图。这种隔离不依赖虚拟化层，而是由内核原生支持，轻量且高效。关键在于：命名空间本身不直接控制权限，但它划定边界；权限的实际约束，需结合用户命名空间、能力集（capabilities）与挂载限制共同实现。
命名空间是隔离的骨架，不是权限的开关
命名空间让容器“看不见”外部资源，但默认情况下，容器内进程仍可能拥有较高权限（比如 root）。例如：
- PID 命名空间让容器内 PID 1 进程仅看到自己命名空间内的进程，但若该进程是 root，它在容器内仍可执行
kill -9或ps aux—— 只是作用范围被限在本命名空间内； - Network 命名空间隔离了网卡、路由表、iptables 规则，但若未禁用
NET_ADMIN能力，容器内 root 仍可修改自身网络栈； - Mount 命名空间提供独立挂载点，但若未设
MS_RDONLY或noexec，容器内进程仍可挂载设备、执行二进制文件。
因此，单纯启用命名空间 ≠ 权限受限。真正提升安全隔离度，必须叠加控制手段。
用户命名空间（User Namespace）是权限降级的关键
这是最有效的权限隔离增强项。它把容器内 UID/GID 映射到宿主机上的非特权用户：
- 容器内 UID 0（root）可映射为主机上 UID 100000，使其无法直接操作主机
/etc/passwd、加载模块或绑定低端口（除非显式授权）； - 需在 Docker 启动时启用：
dockerd --userns-remap=default，或运行时指定--userns=host（禁用）/--userns=private（启用）； - 注意：启用后，容器内
/proc/sys/等路径可能不可写，部分需要特权的操作（如ping）需额外授予CAP_NET_RAW。
结合能力集（Capabilities）最小化特权
Docker 默认丢弃多数危险能力，但仍保留如 CHOWN、SETGID 等。应按需裁剪：
- 禁用不必要的能力：
docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE nginx，只保留绑定端口所需； - 避免使用
--privileged，它会绕过所有命名空间和能力限制，等同于裸进程； - 可通过
capsh --print在容器内查看当前生效的能力列表。
挂载命名空间配合只读与不可执行限制
Mount 命名空间提供隔离基础，但需主动加固：
- 根文件系统设为只读：
docker run --read-only ...，防止篡改配置或植入恶意文件； - 关键路径显式挂载为 tmpfs 或 devtmpfs，并设
noexec,nosuid,nodev； -
/proc、/sys等伪文件系统应以只读方式挂载，或使用--security-opt=no-new-privileges防止提权。
命名空间是容器安全的第一道墙，但它只负责“划界”。真正的权限控制，靠的是用户命名空间的 ID 映射、能力集的精细收放、以及挂载策略的主动约束。三者协同，才能让容器既保持功能性，又远离越权风险。
