用户命名空间

功能状态： Kubernetes v1.30 [beta]

此页面解释了如何在 Kubernetes Pod 中使用用户命名空间。用户命名空间将容器内运行的用户与主机中的用户隔离。

在容器中以 root 身份运行的进程可以在主机中以不同的（非 root）用户身份运行；换句话说，该进程在用户命名空间内拥有操作的完整权限，但在命名空间外的操作是无特权的。

您可以使用此功能来减少受损容器对主机或同一节点中其他 Pod 造成的损害。存在 几个安全漏洞被评为高或严重，当用户命名空间处于活动状态时，这些漏洞无法被利用。预计用户命名空间也将缓解未来的一些漏洞。

开始之前

这是一个仅限 Linux 的功能，并且 Linux 需要对所使用的文件系统上的 idmap 挂载提供支持。这意味着

  • 在节点上，您用于 /var/lib/kubelet/pods/ 的文件系统，或为此配置的自定义目录，需要支持 idmap 挂载。
  • Pod 卷中使用的所有文件系统都必须支持 idmap 挂载。

实际上，这意味着您至少需要 Linux 6.3，因为 tmpfs 在该版本中开始支持 idmap 挂载。这通常是必需的，因为多个 Kubernetes 功能使用 tmpfs（默认挂载的服务帐户令牌使用 tmpfs，Secrets 使用 tmpfs 等）

一些在 Linux 6.3 中支持 idmap 挂载的常用文件系统有：btrfs、ext4、xfs、fat、tmpfs、overlayfs。

此外，容器运行时及其底层 OCI 运行时必须支持用户命名空间。以下 OCI 运行时提供支持

  • crun 版本 1.9 或更高版本（建议使用 1.13+ 版本）。
  • runc 版本 1.2 或更高版本

要将用户命名空间与 Kubernetes 一起使用，您还需要使用 CRI 容器运行时，以便在 Kubernetes Pod 中使用此功能

  • containerd：版本 2.0（及更高版本）支持容器的用户命名空间。
  • CRI-O：版本 1.25（及更高版本）支持容器的用户命名空间。

您可以在 GitHub 上的一个 issue 中查看 cri-dockerd 中用户命名空间支持的状态。

简介

用户命名空间是 Linux 的一项功能，允许将容器中的用户映射到主机中的不同用户。此外，在用户命名空间中授予 Pod 的功能仅在命名空间内有效，在命名空间外无效。

Pod 可以通过将 pod.spec.hostUsers 字段设置为 false 来选择使用用户命名空间。

kubelet 将选择 Pod 映射到的主机 UID/GID，并且会以确保同一节点上的两个 Pod 不使用相同映射的方式进行。

pod.spec 中的 runAsUser、runAsGroup、fsGroup 等字段始终指代容器内的用户。

启用此功能时的有效 UID/GID 范围为 0-65535。这适用于文件和进程（runAsUser、runAsGroup 等）。

使用此范围之外的 UID/GID 的文件将被视为属于溢出 ID，通常为 65534（在 /proc/sys/kernel/overflowuid 和 /proc/sys/kernel/overflowgid 中配置）。但是，即使以 65534 用户/组身份运行，也无法修改这些文件。

如果激活用户命名空间，大多数需要以 root 身份运行但无法访问其他主机命名空间或资源的应用，应该可以继续正常运行，而无需进行任何更改。

了解 Pod 的用户命名空间

某些容器运行时及其默认配置（如 Docker Engine、containerd、CRI-O）使用 Linux 命名空间进行隔离。也存在其他技术，也可以与这些运行时一起使用（例如，Kata Containers 使用 VM 而不是 Linux 命名空间）。此页面适用于使用 Linux 命名空间进行隔离的容器运行时。

创建 Pod 时，默认情况下，会使用几个新的命名空间进行隔离：网络命名空间用于隔离容器的网络，PID 命名空间用于隔离进程视图等。如果使用用户命名空间，这将隔离容器中的用户与节点中的用户。

这意味着容器可以以 root 身份运行，并映射到主机上的非 root 用户。在容器内部，该进程会认为它正在以 root 身份运行（因此 apt、yum 等工具可以正常工作），而实际上，该进程在主机上没有权限。您可以验证这一点，例如，如果您从主机执行 ps aux 来检查容器进程正在哪个用户下运行。ps 显示的用户与您在容器内执行命令 id 时看到的用户不同。

此抽象限制了可能发生的事情，例如，如果容器设法逃逸到主机。鉴于容器在主机上以非特权用户身份运行，它可以对主机执行的操作受到限制。

此外，由于每个 Pod 上的用户都将映射到主机中不同的非重叠用户，因此他们可以对其他 Pod 执行的操作也受到限制。

授予 Pod 的能力也仅限于 Pod 用户命名空间，并且在该命名空间外基本无效，某些甚至完全无效。以下是两个示例

  • 如果授予使用用户命名空间的 Pod，则 CAP_SYS_MODULE 不会产生任何影响，Pod 无法加载内核模块。
  • CAP_SYS_ADMIN 仅限于 Pod 的用户命名空间，并且在该命名空间外无效。

如果不使用用户命名空间，以 root 身份运行的容器在发生容器突破的情况下，在节点上具有 root 权限。如果向容器授予了某些能力，则这些能力在主机上也有效。当我们使用用户命名空间时，这些都不成立。

如果您想了解有关使用用户命名空间时发生的变化的更多详细信息，请参阅 man 7 user_namespaces。

设置节点以支持用户命名空间

默认情况下，kubelet 会根据主机的文件和进程使用 0-65535 范围内的 UID/GID 的假设，为 Pod 分配高于 0-65535 范围的 UID/GID，这对于大多数 Linux 发行版来说是标准的。此方法可防止主机和 Pod 的 UID/GID 之间发生任何重叠。

避免重叠对于减轻诸如 CVE-2021-25741 等漏洞的影响非常重要，在这种漏洞中，Pod 可能会读取主机中的任意文件。如果 Pod 和主机的 UID/GID 不重叠，则 Pod 能够执行的操作会受到限制：Pod UID/GID 将与主机的文件所有者/组不匹配。

kubelet 可以为 Pod 使用自定义的用户 ID 和组 ID 范围。要配置自定义范围，节点需要具有

  • 系统中的用户 kubelet（您不能在此处使用任何其他用户名）
  • 已安装的二进制文件 getsubids（shadow-utils 的一部分），并且位于 kubelet 二进制文件的 PATH 中。
  • 为 kubelet 用户配置的从属 UID/GID（请参阅 man 5 subuid 和 man 5 subgid）。

此设置仅收集 UID/GID 范围配置，并且不会更改执行 kubelet 的用户。

您必须遵循为 kubelet 用户分配的从属 ID 范围的一些约束

  • 启动 Pod 的 UID 范围的从属用户 ID 必须是 65536 的倍数，并且还必须大于或等于 65536。换句话说，您不能为 Pod 使用 0-65535 范围内的任何 ID；kubelet 施加此限制是为了使其难以创建意外的不安全配置。

  • 从属 ID 计数必须是 65536 的倍数

  • 从属 ID 计数必须至少为 65536 x <maxPods>，其中 <maxPods> 是可以在节点上运行的最大 Pod 数。

  • 您必须为用户 ID 和组 ID 分配相同的范围。如果其他用户的用户 ID 范围与组 ID 范围不一致，则无关紧要。

  • 所有分配的范围都不应与任何其他分配重叠。

  • 从属配置必须只有一行。换句话说，您不能有多个范围。

例如，您可以将 /etc/subuid 和 /etc/subgid 定义为对 kubelet 用户具有以下条目

# The format is
#   name:firstID:count of IDs
# where
# - firstID is 65536 (the minimum value possible)
# - count of IDs is 110 (default limit for number of) * 65536
kubelet:65536:7208960

与 Pod 安全准入检查集成

功能状态： Kubernetes v1.29 [alpha]

对于启用用户命名空间的 Linux Pod，Kubernetes 会以受控的方式放宽对 Pod 安全标准的应用。此行为可以通过 特性门控 UserNamespacesPodSecurityStandards 来控制，这允许最终用户提前选择加入。如果使用此特性门控，管理员必须确保集群中的所有节点都启用了用户命名空间。

如果您启用相关的特性门控并创建使用用户命名空间的 Pod，即使在强制执行 Baseline 或 Restricted Pod 安全标准的上下文中，以下字段也不会受到约束。此行为不存在安全问题，因为用户命名空间中的 root 实际上是指容器内的用户，该用户永远不会映射到主机上的特权用户。以下是在这些情况下不对 Pod 进行检查的字段列表：

  • spec.securityContext.runAsNonRoot
  • spec.containers[*].securityContext.runAsNonRoot
  • spec.initContainers[*].securityContext.runAsNonRoot
  • spec.ephemeralContainers[*].securityContext.runAsNonRoot
  • spec.securityContext.runAsUser
  • spec.containers[*].securityContext.runAsUser
  • spec.initContainers[*].securityContext.runAsUser
  • spec.ephemeralContainers[*].securityContext.runAsUser

限制

当为 Pod 使用用户命名空间时，不允许使用其他主机命名空间。特别是，如果您设置 hostUsers: false，则不允许设置以下任何项：

  • hostNetwork: true
  • hostIPC: true
  • hostPID: true

下一步

此页面上的项目引用了由第三方产品或项目提供的、Kubernetes 所需的功能。Kubernetes 项目作者不对这些第三方产品或项目负责。有关更多详细信息，请参阅 CNCF 网站指南。

在提议添加额外的第三方链接的更改之前，您应该阅读内容指南。

上次修改时间：2024 年 11 月 2 日凌晨 2:40 PST：内容：更新 runc v1.2 和 containerd v2.0 的 UserNS 文档 (b127822e20)