这篇文章已发表一年多。旧文章可能包含过时的内容。请检查页面中的信息自发布以来是否发生变化。

Kubernetes 1.25：Pod 用户命名空间 Alpha 支持

作者：Rodrigo Campos (Microsoft), Giuseppe Scrivano (Red Hat) |

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

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

工作原理是什么？

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

用户命名空间是 Linux 的一个特性，它允许将容器中的一组用户映射到主机中的不同用户，从而限制进程可以实际使用的 ID。此外，在新的用户命名空间中授予的权能不适用于主机初始命名空间。

为什么它很重要？

用户命名空间重要的主要有两个原因：

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

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

在用户命名空间中，我们可以将 Pod 内的 root 用户映射到容器外部的一个非零 ID；容器认为自己是以 root 运行，而从主机视角来看，它们只是一个普通的非特权 ID。

进程可以保留通常仅限于特权 Pod 的权能，并且以安全的方式进行，因为在新用户命名空间中授予的权能不适用于主机初始命名空间。

如何启用用户命名空间？

目前，用户命名空间的支持是可选加入的，因此你必须在 Pod Spec 中将 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：

你也可以直接联系我们：

  • GitHub / Slack：@rata @giuseppe