Kubernetes v1.36：Kubernetes 中的 User Namespaces 终于达到 GA

经过数年的开发，Kubernetes 中的 User Namespaces 支持随 v1.36 版本达到通用可用（GA）。这是一项仅限 Linux 的功能。

对于从事底层容器运行时和 rootless 技术的人来说，这是一个期待已久的里程碑。我们终于到了可以将“rootless”安全隔离用于 Kubernetes 工作负载的阶段。

这一功能还支持一种关键模式：在具有权限的情况下运行工作负载，同时仍被限制在用户命名空间内。当设置 hostUsers: false 时，CAP_NET_ADMIN 等能力会被命名空间化，这意味着它们仅赋予对容器本地资源的管理权限，而不会影响主机。这实际上支持了以前如果不运行完全特权容器就无法实现的新用例。

UID 0 的问题

在容器内以 root 身份运行的进程，从内核角度看也会被视为主机上的 root。如果攻击者通过内核漏洞或配置错误的挂载设法逃逸出容器，他们就会成为主机上的 root。

虽然运行容器时有许多安全措施，但这些措施并不会改变进程的底层身份；它仍然拥有 root 的某些“部分”。

引擎：ID-mapped mounts

走向 GA 的道路并不只是关于 Kubernetes API；它还关乎让内核为我们发挥作用。在早期阶段，最大的阻碍之一是卷所有权。如果将容器映射到较高的 UID 范围，Kubelet 就必须递归地对挂载卷中的每个文件执行 chown，以便容器能够读写它们。对于大型卷来说，这是一项非常昂贵的操作，会破坏启动性能。

关键推动因素是 ID-mapped mounts（在 Linux 5.12 中引入，并在后续版本中改进）。内核不是在磁盘上重写文件所有权，而是在挂载时对其进行重新映射。

当启用 User Namespaces 的卷被挂载到 Pod 中时，内核会对 UID（用户 ID）和 GID（组 ID）执行透明转换。对容器而言，这些文件看起来由 UID 0 拥有。在磁盘上，文件所有权保持不变——无需 chown。这是一个 O(1) 操作，瞬时且高效。

在 Kubernetes v1.36 中使用它

使用用户命名空间很直接：你只需在 Pod spec 中设置 hostUsers: false。不需要更改容器镜像，也不需要复杂配置。接口仍然是 Alpha 阶段引入的同一个接口。在 Pod（或 PodTemplate）的 spec 中，你显式选择不使用主机用户命名空间：

apiVersion: v1
kind: Pod
metadata:
  name: isolated-workload
spec:
  hostUsers: false
  containers:
  - name: app
    image: fedora:42
    securityContext:
      runAsUser: 0

有关用户命名空间在实践中如何工作，以及被缓解的 HIGH 级 CVE 演示的更多细节，请参见此前的博客文章：User Namespaces alpha、User Namespaces stateful pods in alpha、User Namespaces beta 和 User Namespaces enabled by default。

参与其中

如果你对用户命名空间感兴趣或想要贡献，以下是一些有用链接：

• User Namespaces 文档
• KEP-127：支持 User Namespaces
• 正文：SIG Node

致谢

这一功能已酝酿多年：第一个 KEP 由其他贡献者在 10 年前提出，而我们在过去 6 年里一直在积极推进。我们感谢所有在 SIG Node、容器运行时和 Linux 内核方面做出贡献的人。特别感谢评审者和早期采用者，他们通过多轮 alpha 和 beta 周期帮助塑造了设计。

• ← 上一篇
• 下一篇 →