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