本文发布已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已不正确。

Kubernetes 1.25：alpha 支持使用用户命名空间运行 Pod

作者：Rodrigo Campos（微软）、Giuseppe Scrivano（红帽） |

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 规范节下将 hostUsers 设置为 false 来为 Pod 启用它

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

此功能位于功能门后，因此请确保在可以使用新功能之前启用 UserNamespacesStatelessPodsSupport 门。

运行时还必须支持用户命名空间

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

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

在 cri-dockerd 中对此的支持 尚未计划。

如何参与？

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

您也可以直接联系我们

  • GitHub / Slack：@rata @giuseppe