Linux 容器内核隔离实战：Namespace 资源视图隔离与 Cgroup 资源限额深度解析

容器技术（Container）作为云原生的基础设施，其底层依赖于 Linux 内核的两大核心机制——Namespace 隔离与 Cgroup（Control Group）资源限额。Namespace 负责"看不见"，控制进程能看到的系统资源视图；Cgroup 负责"用不了"，限制进程能使用的资源上限。本文将深入内核源码级别，详解每种 Namespace 类型的工作机制、Cgroup 的层级控制原理、容器运行时的实践应用，以及容器安全与逃逸攻防。

一、Namespace 隔离：构建独立视图

Linux Namespace 是通过三个关键系统调用（clone、unshare、setns）实现的资源隔离机制。内核通过为不同 Namespace 维护独立的资源实例，使每个 Namespace 中的进程拥有独立的系统资源视图。 Namespace 的隔离能力由 include/linux/nsproxy.h 中的 struct nsproxy 结构体统一管理，每个进程描述符 task_struct 中的 nsproxy 指针指向当前进程所属的 Namespace 集合。

1.1 Mount Namespace (mnt)

Mount Namespace（CLONE_NEWNS）是最早在 Linux 2.4.19 引入的 Namespace 类型。它隔离的是进程看到的文件系统挂载点列表。不同 Mount Namespace 中的进程看到的文件系统层次结构可以完全不同。

关键特性：在新建 Mount Namespace 中，子进程会继承父进程的挂载点副本，但之后的挂载/卸载操作仅影响当前 Namespace。这为容器的根文件系统切换（pivot_root/chroot）提供了基础。容器运行时通过 OverlayFS 在 Mount Namespace 中挂载一个合并的根文件系统层，使得容器看到的是一个独立而完整的 Linux 目录树，但实际上底层共享只读镜像层。

1.2 PID Namespace (pid)

PID Namespace（CLONE_NEWPID）使不同 Namespace 中的进程拥有独立的 PID 空间。每个 PID Namespace 内部从 1 号进程开始编号，且每个 PID Namespace 内部都可以有自己的 1 号 init 进程。

实现机制：内核通过 pid_namespace 结构体维护一个 Namespace 内部的 PID 映射关系。当进程调用 getpid() 时，内核返回其在当前 PID Namespace 中的 PID。嵌套 PID Namespace 支持外层进程看到内层进程，但内层进程无法感知外层进程，层级深度由 PID_MAX_LEVEL（当前为 32）限制。

实践意义：容器内部的 1 号进程通常是容器的主业务进程，当它退出时，内核会向同一 PID Namespace 内的所有其他进程发送 SIGKILL 信号，实现整个容器的优雅终止或强制清理。

1.3 Network Namespace (net)

Network Namespace（CLONE_NEWNET）提供独立的网络协议栈资源，包括网络设备、路由表、iptables 规则、socket 等。每个新创建的 Network Namespace 默认仅包含一个环回设备（lo）。

网络隔离方案：容器运行时通常会在 Host 容器之间建立一对 veth pair（虚拟以太网设备），一端在 Host 的 Network Namespace 中连接到网桥（如 docker0 或 cni0），另一端移入容器的 Network Namespace 中作为 eth0。容器内部的网络通信通过 veth → 网桥 → NAT/路由到达外部网络。

高级模式：CNI（Container Network Interface）插件可以调用 Calico、Flannel、Cilium 等网络方案，分别实现 BGP 路由模式、VXLAN 覆盖网络、eBPF 加速的 L3-L7 策略控制。其中 Cilium 利用 eBPF 在内核态直接处理数据包转发和负载均衡，绕过传统的 iptables/bridge 路径，实现接近宿主机原生网络的性能。

1.4 IPC Namespace

IPC Namespace（CLONE_NEWIPC）隔离了 System V IPC 对象（信号量、消息队列、共享内存段）和 POSIX 消息队列。

实现细节：每个 IPC Namespace 维护独立的 IPC 资源 ID 空间。同一 Namespace 内的进程可以通过 IPC 对象交互，不同 Namespace 中的进程即使使用相同的 Key 也无法访问同一 IPC 对象。内核通过 ipc_namespace 管理每个 Namespace 的 IPC 资源树和 ID 分配器。

容器中的应用：在共享内存通信场景（如 PostgreSQL 的共享缓冲、Redis 的持久化操作），禁止使用跨 Namespace 的 IPC 共享，迫使容器通过 localhost TCP 或 Unix Domain Socket 通信，增强了安全边界。

1.5 UTS Namespace

UTS Namespace（CLONE_NEWUTS）允许容器拥有独立的主机名和域名。内核通过 struct uts_namespace 保存 nodename 和 domainname 字段。Docker 在启动容器时默认分配一个随机容器 ID 作为主机名，也可以通过 --hostname 自定义。

1.6 User Namespace

User Namespace（CLONE_NEWUSER）是容器安全中最重要的 Namespace 类型，它实现了 UID/GID 的隔离映射。关键在于：一个进程在 User Namespace 内部可以是 root（UID 0），但在 Host 上可能映射到普通非特权用户（如 UID 100000）。

映射关系通过 /proc/[pid]/uid_map 和 /proc/[pid]/gid_map 文件配置，格式为"内部ID 外部ID 长度"。例如 0 100000 65536 表示 Namespace 内的 UID 0 映射到 Host 的 UID 100000，覆盖范围 65536。

安全价值：容器内部的 root 进程在外部仅仅是一个普通非特权用户，不具备系统管理权限。即使容器被攻破，攻击者在 Host 上的攻击面被大幅限制——这是 rootless 容器（如 rootless Docker、Podman）的底层保障。

1.7 Cgroup Namespace

Cgroup Namespace（CLONE_NEWCGROUP）隔离了进程看到的 cgroup 视图。在未使用 Cgroup Namespace 时，容器内的进程通过 /proc/[pid]/cgroup 可以看到 Host 上的完整 cgroup 路径信息，这可能泄露 Host 上的服务部署拓扑。Cgroup Namespace 将其视图重写为相对路径，仅显示在当前 cgroup 子树中的相对位置。

1.8 Time Namespace

Time Namespace（CLONE_NEWTIME）是 Linux 5.6 引入的最新的 Namespace 类型，允许不同容器看到不同的系统时间和单调时钟。这在需要仿真特定时间环境（如金融计算、定时任务测试）的场景下非常实用。内核通过 time_namespace 保存时间和 boottime 的偏移量。

二、Cgroup 资源限额：从 v1 到 v2

Cgroup（Control Group）通过将进程分组成层级树结构，对 CPU、内存、IO、网络等资源进行分配和限制。Cgroup 由 kernel/cgroup/ 目录下的内核代码实现，通过虚拟文件系统（cgroupfs）暴露控制接口。

2.1 Cgroup v1 的架构与缺陷

Cgroup v1 的设计存在"层级结构不统一"的问题：每种资源（CPU、内存、IO）的 cgroup 可以挂载在不同的位置，且进程在不同 cgroup 层级中可以处于不同的组。这种灵活性带来了混乱——一个进程所属的 CPU cgroup 和 Memory cgroup 可能分布在不同的层级树上，难以保证资源策略的一致性。

此外，Cgroup v1 的线程模式限制严格：当某个 cgroup 的 cgroup.procs 文件被写入一个线程时，它只能移动该线程而非整个进程，且无法将进程的主线程迁移出 leaf cgroup。这导致容器引擎在多线程应用（如 JVM）的资源控制上苦不堪言。

2.2 Cgroup v2 统一层级设计

Cgroup v2 从根本上解决了 v1 的架构缺陷，核心变化是"统一层级"（Unified Hierarchy）。在 v2 中，所有资源控制使用相同的 cgroup 层级树，进程只能出现在 leaf cgroup 的 cgroup.procs 中，非 leaf cgroup 不包含任何进程（仅做资源分发）。

关键文件说明：

• cgroup.controllers —— 列出当前 cgroup 启用的控制器。
• cgroup.subtree_control —— 配置子 cgroup 能够启用哪些控制器。
• memory.max —— 内存硬限制（OOM Kill 触发阈值）。
• memory.high —— 内存软限制（触发回收压力但不 Kill）。
• cpu.max —— CPU 带宽限制，格式 "quota period"（如 "50000 100000" 表示 0.5 核）。
• io.max —— IO 带宽限制，按设备号分别配置。
• pids.max —— 进程数限制，防止 fork bomb。

Threaded Mode（5.14 引入）：Cgroup v2 为支持多线程应用提出了线程化控制器。一个 leaf cgroup 可以设置为线程模式，允许内部线程分配到不同的子 thread cgroup，不影响进程组级别的整体限制。

2.3 Cgroup 在容器引擎中的运行机制

以 Docker 为例，启动容器时的 Cgroup 配置流程：

1. Docker 在 Host 的 cgroup v2 层级下创建 /sys/fs/cgroup/docker/[containerID]/ 子 cgroup。
2. 根据 --cpus 参数写入 cpu.max，根据 --memory 参数写入 memory.max 和 memory.swap.max。
3. 将容器 init 进程的 PID 写入 cgroup.procs。
4. 容器内所有后续进程（包括通过 exec 进入的进程）自动继承到同一 cgroup。
5. 容器退出后，Docker 清理该 cgroup 节点。

三、内核安全加固：Capabilities 与 Seccomp

Namespace 和 Cgroup 解决了"隔离"问题，但容器内的 root 进程仍然拥有大量的 Linux Capability。Linux 将传统的 root 超级权限拆分为约 40 项细粒度能力（如 CAP_NET_ADMIN、CAP_SYS_ADMIN 等）。容器运行时默认会 drop 大部分 Capability，仅保留最小必需集。

Seccomp（Secure Computing Mode）进一步限制了容器可用的系统调用。Docker 的默认 Seccomp Profile 禁止了约 44 个危险系统调用（如 kexec_load、init_module、perf_event_open），防止容器加载内核模块或逃逸。

此外，AppArmor / SELinux 强访问控制（MAC）为容器提供了额外的安全层。例如，AppArmor 可以禁止容器对 Procfs 的敏感文件读取（如 /proc/sys/kernel/core_pattern），SELinux 则通过类型为 container_t 的强制策略限制容器的文件访问范围。

四、容器逃逸攻击与防御

容器逃逸是指攻击者从容器内部突破 Namespace/Cgroup 隔离，获得 Host 上更高权限的行为。常见的逃逸路径包括：

特权容器逃逸：当容器以 --privileged 启动时，所有 Capability 被保留，且 Host 上所有设备节点在容器内可见。攻击者可通过挂载 Host 的 / 文件系统到容器（mount /dev/sda1 /mnt），然后 chroot 到 Host 文件系统，进而修改 Host 的 crontab 或 authorized_keys。

挂载逃逸：不当的 -v /var/run/docker.sock:/var/run/docker.sock 挂载可以让容器访问 Docker Socket，从而控制守护进程，创建新的特权容器实现逃逸。

内核漏洞利用：通过 User Namespace 触发内核内存破坏漏洞，可获取 Host 系统 root 权限。近年来多个 CVE 涉及容器逃逸。

防御最佳实践：

• 严禁使用 --privileged 和过多的 Capability 授权。
• 启用 User Namespace 映射（rootless 容器）。
• 挂载只读根文件系统（--read-only）。
• 使用 gVisor / Kata Containers 实现更深层内核隔离。
• 及时更新内核补丁，监控 CVE。

五、实战：手动构建最小容器

抛开 Docker/containerd 等高层工具，可以通过 Namespace 系统调用和 Cgroup 接口手动构建一个理解性的最小容器。

5.1 使用 unshare 构建隔离环境

sudo unshare --user --mount --pid --net --uts --ipc --fork \
  --mount-proc /bin/sh -c 'mount -t proc none /proc