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

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

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