\n\nKubernetes 1.36 引入用户命名空间以增强安全性，通过重映射 UID 减轻容器逃逸影响。但文章指出，由于无法解决共享内核带来的攻击面风险，其隔离性在 AI 驱动的漏洞利用面前仍显不足。
译自：Kubernetes finally lands user namespace support, but shared kernel problem remains
作者：Kaylin Trychon
Kubernetes 上周发布了一个期待已久的安全性功能：Pod 的用户命名空间支持。虽然这在 1.36 版本中听起来像是个晦涩的功能，但它代表了在云原生环境中对抗特定类别特权提升攻击的进展。用户命名空间可以通过防止 Pod 内部的 root 进程被视为宿主机上的 root，来减轻某些容器逃逸的影响。
用户命名空间强化了自 Docker 早期设计决策以来就一直存在的模式：默认以 root 身份运行容器。这一选择从来不是为了安全，而是为了可用性。大多数工作负载根本不需要 root 特权，但整个生态系统是围绕这一假设演进的。用户命名空间在狭义上使这变得更安全，但也使得继续维持这一模式而非消除它变得更加合理。
“用户命名空间在狭义上让情况变得更安全，但也让继续维持这种模式而非彻底消除它变得更加合理。”
但在公告博客文章中，声称“我们终于达到了‘无 root’安全隔离可用于 Kubernetes 工作负载的程度”在我看来是有误导性的。必须理解，虽然用户命名空间可以将 root 重新映射为宿主机上的非特权身份，但如果你在 Kubernetes 环境中仍然共享内核，那么远未到宣告安全隔离胜利的时候。
用户命名空间究竟做了什么
其机制非常直接：当 Pod 设置 hostUsers: false 时，容器的 root 用户 (UID 0) 会被重新映射为宿主机上的一个非特权用户 ID。一个自认为以 root 身份运行的进程，从宿主机内核的角度来看，只是一个普通身份。
如果该进程逃逸了容器边界，它对底层节点没有管理权。像 CAP_NET_ADMIN 这样的能力会被限定在容器的命名空间内，而不是宿主机。这确实非常有用。
Kubernetes 团队指出，用户命名空间本可以缓解多个“高级（HIGH）”和“严重（CRITICAL）”级别的 CVE。这是准确的。当每个 Pod 的 UID 和 GID 映射到宿主机上不重叠的范围时，Pod 之间的横向移动也会变得更加困难。
但我认为，这篇博客文章未能解决用户命名空间无法解决的根本架构限制。
内核共享仍然是那个“房间里的大象”
用户命名空间重新映射身份，但它们并不隔离内核。
用户命名空间重新映射身份，但也扩大了非特权工作负载可触及的内核攻击面。以前仅限于特权上下文的功能，现在可以通过命名空间抽象进行访问。这就是为什么用户命名空间经常作为现代内核漏洞利用链的前置条件出现：它们本身不引入漏洞，但使现有漏洞变得可触及。
Kubernetes 节点上的每个容器——无论是否设置 hostUsers: false——都与该节点上的所有其他容器共享同一个 Linux 内核。内核处理所有系统调用（syscalls），管理内存、网络、设备和调度。它是每个工作负载之下的共同基础，并且可以从每个容器中访问。
这意味着内核漏洞利用可以完全绕过用户命名空间隔离。如果攻击者在内核子系统中发现了漏洞——而 Linux 内核的 CVE 历史清楚地表明这些漏洞经常被发现——用户命名空间就毫无用处了。攻击者运行的层级低于用户命名空间保护存在的层级。
公告文章承认，在没有用户命名空间的情况下，“容器内以 root 运行的进程在内核看来也是宿主机上的 root”，并将用户命名空间定位为修复方案。但这个修复方案解决的是 UID 层，而不是内核攻击面。这是两个不同的问题。混淆它们可能会误导操作人员，使他们相信多租户工作负载比实际情况更隔离。
这不是理论上的风险。多租户 Kubernetes 环境——云提供商、AI 平台、在共享节点上运行不同客户工作负载的 SaaS 公司——面临着真正的对手，他们有动力寻找并利用内核漏洞。用户命名空间虽然减少了某些容器逃逸的爆炸半径。
但风险在于它们被解读为全面的隔离边界，而实际上它们只是叠加在共享内核模型之上的针对性缓解措施。它们并没有改变共享内核的威胁模型。
为什么这种区别在当下很重要
如果说 Kubernetes 的公告是审慎乐观的理由，那么 AI 辅助漏洞开发的出现则是紧迫性的理由。
本月早些时候，Anthropic 发布了 Mythos ——一个能够在所有主流操作系统和浏览器中自主识别零日漏洞的 AI 模型。以前需要数周熟练人工研究的复杂利用链现在可以自主生成，快速迭代，并针对那些建立在“寻找此类漏洞很难”假设之下的基础设施。
其影响是直接的。内核漏洞——正是那类可以完全绕过用户命名空间保护的缺陷——就在 Mythos 的目标之列。该模型已经自主获得了 Linux 上的本地特权提升。这些不是理论攻击，而是云原生基础设施目前正面临的运营现实。
“这就是为什么共享内核是云原生安全的阿喀琉斯之踵。”
这就是为什么共享内核是云原生安全的阿喀琉斯之踵。
真正解决这一问题的架构
用户命名空间留下的共享内核缺口，正是硬件级虚拟化所能填补的。
少数专注于安全的基础设施厂商采取了不同的方法。他们不是在共享内核之上叠加命名空间控制，而是在工作负载和宿主机之间插入一个虚拟机管理程序（hypervisor）边界 ——这意味着每个工作负载都有自己隔离的内核，无论特权级别如何，一个工作负载中的漏洞都无法波及另一个。
Edera 采取了这种方法。Edera 基于 Rust 重写的 Type 1 Xen 虚拟机管理程序构建，为 Kubernetes 环境中的容器和 GPU 工作负载提供硬件强制隔离。每个工作负载运行在自己的 VM 边界内，而不仅仅是自己的命名空间。容器内的内核漏洞没有通往宿主机或相邻工作负载的路径——因为没有可供利用的共享内核。
用户命名空间为 Kubernetes 内置的安全态势提供了有意义的增量改进，而 Edera 则提供了截然不同的威胁模型：它将内核本身视为不可信的，而不只是限制被攻破的进程在其中能做什么。
对于运行真正的多租户工作负载——AI 推理流水线、不可信代码执行、受监管的数据环境——的组织来说，这种区别并不微妙。它是减小爆炸半径与彻底消除爆炸路径之间的区别。
当威胁的时间线从几周压缩到几小时，响应式安全就输了。“检测并响应”假设你有时间去响应，而主动性架构则假设你没有时间。
Kubernetes 社区通过 v1.36 提升了安全基准。这很重要。但用户命名空间并没有改变根本的权衡：共享内核仍然是共享的单点故障，让 root 变得更安全的抽象并不能消除最初以高特权运行的风险。
改变 root 的行为不等于改变它能触及的范围。在边界移动到内核层级以下以前，失效模式将保持不变。全 工智能
