Kubernetes命名空间提供逻辑分区而非运行时隔离，这在多租户和AI工作负载中构成安全风险。仅依赖命名空间不足以抵御攻击，真正的隔离需强化运行时和轻量级虚拟化。
译自：Beyond Namespaces: Why Kubernetes Needs Real Workload Isolation
作者：Lewis Denham-Parry
Kubernetes 命名空间是平台工程师工具包中最熟悉的工具之一。在 The New Stack 发表的一篇文章中，命名空间被视为实现容器隔离的分步指南，这种观点反映了许多团队目前使用它们的方式。
然而，“隔离”这个词在这种框架下承担了过多的含义。命名空间提供了逻辑上的分离，但它们无法强制执行那种强化的边界，能够阻止工作负载在运行时相互干扰。
这种区别不仅仅是语义上的——它关乎架构。在当今多租户集群、AI驱动工作负载和GPU共享的世界中，这种区别决定了你的集群能否抵御入侵，还是像纸牌屋一样崩溃。
命名空间是分区，而非隔离
命名空间为开发者和运维人员提供了一种优雅的抽象：它们允许多个团队或租户共享一个集群，而不会相互踩踏资源。它们强制执行配额，启用基于角色的访问控制（RBAC），并允许更清晰地划定策略范围。这对于减少管理混乱是无价的。
但命名空间并未改变所有运行在同一节点上的容器共享同一个内核这一基本事实。一个命名空间中受损的容器仍然有可能攻击内核，利用共享设备或窥探GPU内存，因为内核本身就是共享表面。
Amber Wolf 关于命名空间边界的文章通过真实世界的例子强调了这一点。当租户管理员被赋予完整的命名空间控制权时，他们通常仍保留影响整个集群的途径。红队经验表明，命名空间边界在压力下无法坚守。它们是策略结构，而非安全屏障。
这种区别之所以重要，是因为我们经常谈论命名空间和隔离，仿佛它们可以互换。它们不能。命名空间提供了分区。隔离是指对工作负载进行严格约束，即使其中一个受到损害，也无法跨越边界。
仅凭命名空间不足以实现多租户安全
命名空间的局限性在现代攻击模式中表现得尤为突出。容器逃逸和内核级漏洞说明了这个问题：
- GPU 逃逸： Wiz 记录了 NVIDIA 漏洞，允许攻击者通过利用钩子和环境变量处理来逃逸容器边界。命名空间对此无能为力，因为攻击是针对共享内核状态执行的。
- 权限提升： 一旦进入内核，攻击者就可以提升权限，损害相邻的工作负载并在节点间横向移动。
- 爆炸半径： 在仅依赖命名空间的模型中，一个受损的 Pod 可能会引发级联故障，影响节点上的每个工作负载。在受监管行业或 SaaS 多租户环境中，这是不可接受的。
将命名空间视为强化边界的安全模型依赖于一个危险的误解：即逻辑分离等同于运行时隔离。一旦容器突破到内核，一切都将失控。
历史对比：虚拟机与容器
值得记住的是，虚拟化在几十年前就解决了这个问题。虚拟机（VM）通过为每个工作负载提供自己的内核来强制执行硬边界。一个虚拟机不能轻易地干扰另一个。容器为了速度、密度和敏捷性而放弃了这一点——这些权衡在当时是合理的。
但时代变了。轻量级虚拟化和基于管理程序的运行时已经缩小了曾经使虚拟机吸引力下降的性能差距。半虚拟化和 Type-1 管理程序现在提供了接近原生的性能，同时恢复了命名空间所缺乏的强大隔离特性。
苹果最近通过其新的 Container Framework 验证了这种方法，该框架在虚拟机支持的边界内运行容器。Kata Containers、Firecracker 以及 Edera 等较新的强化运行时项目，都将同样的原则带到了 Kubernetes。教训很清楚：我们不再需要在速度和安全之间做出选择。
为什么命名空间无法作为安全边界
要了解为什么命名空间不等于隔离，我们需要深入研究 Linux 内核本身。
- 命名空间 隐藏进程ID、文件系统和网络接口等资源。它们改变了容器所看到的内容。
- Cgroups 控制容器可以消耗多少CPU或内存。它们规定了容器的使用量。
- Seccomp 和 AppArmor 限制系统调用或强制执行配置文件，但它们仍然在共享内核内部运行。
这些机制都无法阻止一个受损的容器攻击内核或利用漏洞影响其他租户。充其量，它们限制了可见性和资源使用。它们不提供现代工作负载所需的加密或硬件支持的保证。
对比一下管理程序级别的隔离：
- 每个容器（或 Pod）都在具有自己内核的轻量级虚拟机中运行。
- 没有共享内核状态意味着一个虚拟机中的逃逸漏洞不会暴露主机或其他租户。
- GPU 和设备访问可以虚拟化，从而消除工作负载之间的侧信道泄露。
这就是分区与保护之间的区别。
案例研究：CVE-2025-23266
考虑 CVE-2025-23266，一个三行 NVIDIA 容器逃逸漏洞，允许攻击者实现主机级入侵。该漏洞之所以有效，是因为特权钩子在共享内核上下文中执行。一个恶意容器可以通过 LD_PRELOAD 注入一个库并立即逃逸。
仅凭命名空间，这次攻击就成功了。如果采用管理程序级别的隔离，它将被限制住。恶意库永远不会触及主机内核——它只会影响到被隔离的客户机。这个例子突显了为什么命名空间不能成为最后一道防线。
强化运行时的兴起
这就是强化运行时发挥作用的地方。强化运行时通过以下方式颠覆了传统模型：
- 强制真正的执行隔离 – 具有独立内核的沙盒区域，没有对对等容器或设备的隐式访问。
- 最小化攻击面 – 剥夺不必要的权限，阻止无范围的系统调用并消除主机可见性。
- 实时遏制威胁 – 在出现异常时切断网络访问或暂停执行。
结果是，整类攻击——权限提升、横向移动、内核逃逸——在结构上变得不可能，而不仅仅是更难检测。
为什么这对于AI和GPU工作负载很重要
AI 使解决这个问题变得更加紧迫。AI 代理不仅分析数据，它们还执行代码，持有凭证并与内部系统交互。与此同时，GPU 在多个租户和工作负载之间共享，通常带有暴露的驱动程序和内存接口。侧信道泄露在这里并非理论，它已在实践中得到证实。
当命名空间是唯一的控制手段时，AI 工作负载仍然容易受到困扰传统容器环境的相同类别的逃逸和权限提升攻击。具有真正隔离边界的强化运行时是大规模防御这些风险的唯一方法。
关于隔离的更清晰对话
那么这给我们带来了什么启示？命名空间至关重要：它们组织集群，强制执行策略，并使多团队操作易于管理。但它们不应与隔离混淆。如果 Kubernetes 是开发者、基础设施工程师和安全团队之间的契约，那么命名空间就是管理条款。然而，真正的隔离是在运行时强制执行的。
作为一个行业，我们需要停止混淆这两者。逻辑分离不同于运行时保护。前者减少混乱；后者防止违规。
好消息是，我们无需放弃 Kubernetes 或容器就能实现这一点。轻量级虚拟化、强化运行时和基于管理程序的容器已经存在，并且它们与 Kubernetes API 无缝集成。技术已经成熟。所需要的是清晰的认识以及改变我们对隔离看法的意愿。
分区与保护
为了构建安全、有弹性的基础设施，我们需要重新审视这个问题。命名空间很有价值，但它们不提供隔离。真正的隔离需要运行时而非仅在控制平面运行的架构边界。
下次有人说命名空间提供了隔离时，请记住这一点：分区不是保护。如果你的工作负载很重要——如果合规性、多租户或AI安全面临风险——那么仅凭命名空间是不够的。
业界必须超越隔离的幻觉，拥抱真正强制执行隔离的运行时环境。
