Kubernetes 1.25：对使用用户名字空间运行 Pod 的 alpha 支持

Kubernetes v1.25 引入了对用户名字空间的支持。

这对于在 Kubernetes 中运行安全工作负载而言是一个重大改进。每个 Pod 只能访问系统上可用 UID 和 GID 的有限子集，从而增加了一个新的安全层，以保护其免受在同一系统上运行的其他 Pod 的影响。

它是如何工作的？

在 Linux 上运行的进程最多可以使用 4294967296 个不同的 UID 和 GID。

用户名字空间是一项 Linux 功能，允许将容器中的一组用户映射到主机上的不同用户，从而限制进程可以有效使用的 ID。此外，在新的用户名字空间中授予的能力（capabilities）并不适用于主机的初始名字空间。

为什么它很重要？

用户名字空间之所以重要，主要有两个原因

• 提高安全性，因为它们限制了 Pod 可以使用的 ID，因此每个 Pod 都可以使用唯一的 ID 在其独立的隔离环境中运行。

• 能够以更安全的方式运行 root 工作负载。

在用户名字空间中，我们可以将 Pod 内的 root 用户映射到容器外的非零 ID，这样容器就认为自己以 root 身份运行，而从主机的角度来看，它们只是一个常规的非特权 ID。

该进程可以保留通常仅限于特权 Pod 的能力，并且可以安全地做到这一点，因为在新的用户名字空间中授予的能力不适用于主机的初始名字空间。

如何启用用户名字空间？

目前，用户名字空间支持是可选的，因此你必须通过在 Pod 规约中将 hostUsers 设置为 false 来为 Pod 启用它。

apiVersion: v1
kind: Pod
spec:
  hostUsers: false
  containers:
  - name: nginx
    image: docker.io/nginx

该功能受特性门控的保护，因此请确保启用 UserNamespacesStatelessPodsSupport 门控后才能使用这一新功能。

运行时也必须支持用户名字空间

• containerd：计划在 1.7 版本中提供支持。有关更多详细信息，请参阅 containerd issue #7063。

• CRI-O：v1.25 已支持用户名字空间。

目前尚无计划在 cri-dockerd 中支持此功能。

我如何参与？

你可以通过多种方式联系 SIG Node

• Slack: #sig-node
• 邮件列表
• 开放的社区问题/PR

你也可以直接联系我们：

• GitHub / Slack: @rata @giuseppe

• ←上一篇
• 下一篇→