Linux容器中Namespace的严格隔离需组合启用PID、Network、MNT、UTS、IPC、User六类基础Namespace，禁用--host等共享模式，强化User Namespace用户映射，并配合Mount Namespace与联合文件系统实现根文件系统隔离。
Linux 容器中 Namespace 的使用限制，不是靠“配置开关”来启用或禁用某类 Namespace，而是通过启动时显式指定隔离维度 + 禁用共享模式 + 强化映射机制实现的。Docker 或 containerd 默认已启用 PID、Network、MNT、UTS、IPC 五类 Namespace，但 User Namespace 默认关闭——而这恰恰是严格隔离的关键一环。
以下四类操作共同构成 Namespace 的实际“限制配置”：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
1. 启动容器时强制启用全部基础 Namespace
Docker 默认不启用 User Namespace，也不自动启用 Time 或 Cgroup Namespace。需手动干预：
- 使用
--userns=auto或提前配置userns-remap（在/etc/docker/daemon.json中添加"userns-remap": "default"并重启 dockerd） - 避免
--pid=host、--network=host、--ipc=host、--uts=host等参数，它们会直接绕过对应 Namespace 隔离 - 若需 Time 或 Cgroup Namespace，需内核 ≥ 5.6 且显式加参数：
--time=private或--cgroupns=private
2. 关闭隐性共享通道，堵住隔离漏洞
即使启用了所有 Namespace，若挂载了敏感宿主机路径，隔离即失效：
- 不挂载
/proc/sys、/sys/fs/cgroup、/dev全局设备节点 - 用
--device /dev/sda:/dev/xvda:rwm替代-v /dev:/dev - 启动时
--cap-drop=ALL，再按需--cap-add=NET_ADMIN等，而非保留默认能力集 - 绝对禁用
--privileged——它会无视所有 Namespace 边界
3. 配合 Mount Namespace 实现文件系统真正隔离
Mount Namespace 本身只隔离挂载视图，不自动提供独立根文件系统：
- 必须搭配 overlay2、btrfs 等联合文件系统，由容器运行时自动构建 layer 叠加
- 手动测试时可用
unshare --mount --fork+chroot或pivot_root构建干净 rootfs - 禁止使用
mount --bind /host/path /container/path暴露宿主机目录，除非明确需要且做了权限裁剪
4. 在 Kubernetes 中通过 Namespace 对象间接约束资源可见性
K8s 的 Namespace（注意：和 Linux Namespace 不同名但有关联）不直接控制底层隔离，但能配合限制：
- 为 K8s Namespace 设置
ResourceQuota，限制该空间下 Pod 总量、CPU/内存上限、ConfigMap 数量等 - 配置
LimitRange，为该 Namespace 内所有容器设置默认requests和limits - 结合 PodSecurityPolicy（或新版 Pod Security Admission），禁止
hostPID: true、hostNetwork: true等破坏 Namespace 隔离的字段
真正严格的 Namespace 限制，本质是组合策略：启用全维度 + 切断共享路径 + 映射非特权用户 + 运行时加固。单靠某一条配置无法达成“极其严格”的隔离效果。
