Namespace 提供基础隔离但不保安全，需协同 User Namespace、Capabilities、SELinux/seccomp 等多层机制实现纵深防御。
Namespace 是 Linux 内核提供的核心隔离机制，它让容器能拥有独立的视图（如进程、网络、挂载点等），但仅靠 Namespace 无法实现真正的安全隔离。用户隔离与权限控制必须结合 User Namespace、Capabilities、SELinux/AppArmor 等多层机制协同生效，否则容器内 root 仍可能逃逸或提权。
User Namespace：让容器“假 root”真正受限
User Namespace 是实现用户级隔离的关键。它允许将宿主机 UID/GID 映射为容器内的不同 ID，使容器中 UID 0（root）在宿主机上实际对应一个普通非特权 UID，从而限制其真实权限。
- 启用方式：Docker 默认已开启（需内核支持且未被禁用），可通过
docker info | grep "userns"确认；Podman 默认启用，可显式加--userns=auto自动分配子 UID/GID 范围 - 关键配置：宿主机需预先在
/etc/subuid和/etc/subgid中为用户分配足够范围（如alice:100000:65536），否则容器启动失败 - 注意：若容器镜像内应用硬编码依赖 UID 0（如某些旧版 MySQL 启动脚本），需同步调整其配置或使用
USER指令指定非 root 用户启动
Capabilities：按需授予最小权限
Linux Capabilities 将 root 权限拆分为细粒度能力（如 CAP_NET_BIND_SERVICE、CAP_SYS_ADMIN）。容器默认只保留必要能力，应避免使用 --privileged 或盲目添加 --cap-add=ALL。
- 常见合理添加项：
--cap-add=NET_BIND_SERVICE允许绑定 1024 以下端口；--cap-add=CHOWN支持修改文件属主（配合非 root 用户时常用） - 禁止添加项：
CAP_SYS_ADMIN几乎等同于 root 权限，极易引发逃逸；CAP_DAC_OVERRIDE可绕过文件读写权限检查，风险极高 - 验证方式：进入容器后执行
capsh --print查看当前进程拥有的 capabilities
补充加固：SELinux、seccomp 与只读文件系统
Namespace 和 Capabilities 属于基础隔离，生产环境还需叠加策略型防护：
- SELinux：通过
--security-opt label=type:spc_t（Podman）或--security-opt seccomp=unconfined（慎用）控制进程域；推荐使用预定义策略如container_t限制容器对宿主机资源的访问路径 - seccomp：过滤系统调用，Docker 默认加载
default.json，禁止危险调用（如clone、mount、keyctl）；可定制策略禁用ptrace防止调试注入 - 只读根文件系统：
--read-only强制容器运行时不可写根层，配合--tmpfs /tmp或-v /host/path:/container/path:rw按需开放可写挂载点
运行时用户与组管理实践
镜像构建阶段就应明确运行身份，而非依赖运行时覆盖：
- Dockerfile 中优先使用
USER 1001:1001（非 0），并确保该 UID 在镜像内存在（可通过groupadd -g 1001 app && useradd -u 1001 -g app app创建） - Kubernetes 中通过
securityContext.runAsUser、runAsGroup和fsGroup统一管控；启用MustRunAsNonRootPodSecurityPolicy 或 Pod Security Admission（v1.25+）强制拦截 root 启动 - 避免使用
sudo或su在容器内提权——它们在无特权容器中通常失效，且违背最小权限原则
不复杂但容易忽略：隔离效果取决于最弱一环。比如开了 User Namespace 却给了 CAP_SYS_ADMIN，或禁用了 seccomp 却以为 Namespace 足够安全。每层机制要各司其职，才能形成纵深防御。
