Kubernetes 1.30：对带用户命名空间的 Pod 的测试支持
内容提要
Linux 提供用户命名空间以隔离容器内的用户和组标识符（UID 和 GID），增强安全性。Kubernetes 1.30 将用户命名空间功能移至测试阶段，允许容器以 root 身份运行，但限制与主机的交互权限，从而降低容器突破的风险。该功能依赖于 Linux 6.3 及以上版本，支持 CRI-O 和 containerd。
延伸解读
用户命名空间如何提升容器安全
用户命名空间通过将容器内的 UID 和 GID 映射到主机上非特权且不重叠的标识符，实现两层防护：一是防止横向移动，不同容器的标识符在主机上不同，即使逃逸也难以访问其他容器的文件；二是增强主机隔离，容器内 root 在主机上无特权，能力仅限命名空间内，从而大幅降低容器逃逸的影响。
CVE-2024-21626 的缓解效果
CVE-2024-21626 是一个高危漏洞，允许攻击者逃逸容器并读写节点上任意路径及其他 Pod 的文件。使用用户命名空间后，攻击者在主机文件系统上的操作受限于“其他”权限位，因此漏洞未被完全阻止，但影响被大幅降低。这体现了用户命名空间作为纵深防御措施的价值。
部署要求与运行时支持现状
使用用户命名空间需要 Linux 6.3 或更高版本，因为它依赖 idmap mounts 对 tmpfs 的支持。容器运行时方面，CRI-O 1.30 配合 crun 1.9+ 已支持；containerd 计划在 2.0 中支持，同样需要 crun 1.9+。目前 CRI-O 或 containerd 搭配 runc 均不支持。containerd 1.7 虽有实验性支持，但仅适用于 Kubernetes 1.25/1.26，且启动时需更改镜像内所有文件属主，带来存储开销和启动延迟。
Q&A
Kubernetes 1.30 中用户命名空间的主要功能是什么？
Kubernetes 1.30 中用户命名空间的主要功能是允许容器以 root 身份运行，但限制与主机的交互权限，从而增强安全性。
用户命名空间如何增强容器的安全性？
用户命名空间通过隔离容器内的用户和组标识符，防止容器之间的横向移动，并限制容器对主机的权限，从而增强安全性。
使用用户命名空间时，容器的权限如何变化？
使用用户命名空间时，容器即使在内部以 root 身份运行，仍然在主机上没有特权，限制了其对主机文件和进程的访问。
Kubernetes 1.30 对用户命名空间的支持依赖于哪些条件？
Kubernetes 1.30 对用户命名空间的支持依赖于 Linux 6.3 及以上版本，并支持 CRI-O 和 containerd 的特定版本。
CVE-2024-21626 漏洞与用户命名空间有什么关系？
CVE-2024-21626 漏洞允许攻击者逃逸容器，但使用用户命名空间可以大大降低其影响，因为容器在主机上没有特权。
用户命名空间如何防止容器之间的攻击？
用户命名空间通过将不同容器的 UID 和 GID 映射到主机上的不同标识符，限制了容器对彼此的访问，从而防止攻击。
