Kubernetes 支持 docker 用户命名空间重新映射

Question

Docker 支持用户命名空间重新映射，使用户命名空间与主机完全分离。

当前的默认行为确保容器获得自己的用户和组管理，即它们自己的

/etc/passwd

和

/etc/group

版本，但容器进程在主机系统上相同的 UID 下运行。这意味着如果您的容器使用 UID 1（root）运行，它也将以 root 身份在主机上运行。出于同样的原因，如果您的容器安装了 UID 1001 的用户“john”并使用该用户启动其主进程，则在主机上它也将以 UID 1001 运行，该用户可能属于用户“Will”并且也可能具有管理员权限权利。

为了完成用户命名空间隔离，需要启用remapping，它将容器中的UID映射到主机上的不同UID。因此，容器上的 UID 1 将映射到主机上的“非特权”UID。

Kubernetes 是否支持在底层容器运行时启用此功能？开箱即用不会出现任何问题吗？

Answer 1

所以，它还不像 Docker 那样受支持，按照 this（如评论中提到的）和 this。

但是，如果您正在考虑隔离工作负载，还有其他替代方案（虽然不一样，但选项非常好）：

您可以使用 Pod 安全策略，特别是您可以使用 RunAsUser 以及 AllowPrivilegeEscalation=false。 Pod 安全策略可以与 RBAC 绑定，这样您就可以限制用户运行其 Pod 的方式。

换句话说，您可以强制用户仅以“youruser”身份运行 pod，并禁用 pod 中的

privileged

标志

securityContext

。您还可以在容器映像中禁用

sudo

和 。

此外，您可以放弃 Linux Capability，特别是

CAP_SETUID

。更高级的是使用 seccomp 配置文件、使用 SElinux 或 Apparmor 配置文件。

运行不受信任工作负载的其他替代方案（在撰写本文时处于 alpha 状态）：

• 卡塔集装箱
• Nabla 容器
• g遮阳板

Answer 2

Kubernetes 是否支持在底层容器运行时启用此功能？

2024：正如 Akihiro Suda 在 “containerd v2.0、nerdctl v2.0 和 Lima v1.0” 中提到的，containerd 2.0 现在是一个 OCI 运行时，支持用户命名空间，映射 pod 中的用户 ID主机上的不同用户 ID。此功能允许将 pod 中的 root 用户映射到主机上的非特权用户。

请参阅“Pods / 用户命名空间”，以及 Kubernetes v1.30+（2024 年 4 月）（2024 年第 4 季度仍处于测试阶段）。