Kubernetes v1.37 把安全特性「KubeletInUserNamespace」（即 rootless 节点模式）从 Alpha 升级为 Beta，并默认启用。Kubernetes 是目前最流行的开源容器编排平台，负责自动部署、扩容和管理大量容器化应用；rootless 模式的含义是：集群中每台机器上的节点组件——kubelet（节点管理代理）、容器运行时、网络插件、kube-proxy——以宿主机的非 root 普通用户身份运行，而不是最高权限的 root。收益很直接：这些组件一旦被攻破，攻击者拿到的只是普通用户权限，无法直接控制整台宿主机。该特性源于 2018 年的一个实验项目，2021 年以 Alpha（内测）状态合入 Kubernetes v1.22，历经五年打磨后在 v1.37 进入 Beta（公测）。

为什么需要 rootless：容器逃逸漏洞的教训

Kubernetes 的节点组件历史上多次被曝出「容器逃逸」漏洞——攻击者从容器内部突破边界，在宿主机上以 root 执行任意代码。官方博客列举了 5 个真实案例（CVE 是公开漏洞的统一编号）：

  • CVE-2022-0811（cr8escape）：CRI-O 运行时被诱导设置任意系统参数，导致在宿主机以 root 执行任意代码
  • CVE-2023-27561：runc 运行时被利用挂载竞态绕过容器的屏蔽路径，暴露宿主机的 procfs 系统文件
  • CVE-2024-10220：kubelet 通过 gitRepo 卷被诱导以 root 执行任意命令
  • CVE-2025-31133：runc 被诱导绑定挂载攻击者控制的路径，向宿主 procfs 写入数据
  • CVE-2026-53488：containerd 运行时通过容器镜像中的恶意标签在宿主机执行任意命令

rootless 模式压缩的是这类攻击的爆炸半径：把可能被攻破的组件关进普通用户权限的笼子，即便逃逸成功，攻击者也无法篡改内核、引导器或固件。

工作原理：用户命名空间里的“假 root”

rootless 依赖 Linux 内核的用户命名空间（user namespace）——一种把一组用户 ID 映射为另一组 ID 的隔离机制。具体做法是：宿主机把普通用户（如 UID 1000）映射为命名空间内的 UID 0（root）。节点组件在命名空间内拥有 root 级别的权限，可以做挂载卷、创建 cgroup、配置 pod 网络等日常工作，但这些权限被严格限制在命名空间内部；一走出命名空间，它们就只是一个普通用户。

官方博客提醒两点：用户命名空间需要在 Kubernetes 外部预先创建（最常用的是借助 Docker 的 rootless 模式）；部分 CNI/CSI 驱动与该模式存在兼容性问题。另外，用户命名空间对内核自身的漏洞没有缓解作用，仍需配合 seccomp（一种限制容器系统调用的内核安全机制）等传统加固手段使用。

适合谁用

官方列举了几类典型场景：生产集群管理员，用它缩小容器逃逸的破坏范围；共享机器（如高校或公司的 HPC 计算节点）上的用户，不向机器管理员申请 root 权限也能部署 Kubernetes，还不会误伤同机其他人的环境；笔记本用户，本地试验集群不会改坏宿主机的网络配置；还有一类新场景——为 AI 编程助手建沙箱，用一个独立的普通用户账号运行 AI agent 和测试集群，防止 agent 被网络上的恶意信息诱导后破坏宿主机。

与 pod 级用户命名空间的区别

Kubernetes 还有一个相关特性：pod 级用户命名空间（UserNamespacesSupport，v1.36 起 GA）。它把单个 pod 放进用户命名空间，但节点组件仍然以 root 运行。两者互不冲突、可以组合使用；组合之后，甚至可以在一片 Kubernetes 集群内部再嵌套运行一个 Kubernetes 集群（即 Kubernetes-in-Kubernetes）。

Beta 带来的三个变化

  • 特性门默认启用。特性门（feature gate）是 Kubernetes 的功能开关机制；默认启用不等于现有集群会自动进入 rootless——开关只代表「允许使用」，是否真正切换由集群管理员决定，现有以 root 运行的集群不受影响
  • kubectl get nodes -o yaml 现在通过 runningInUserNamespace 属性上报节点是否运行在用户命名空间中，管理员可据此给节点打标签或设置污点，避免把需要真实 root 权限的工作负载调度到 rootless 节点
  • Kubernetes 官方 CI 的节点一致性端到端（e2e）测试已迁移到 rootless 集群上运行，保证该模式持续被真实测试覆盖

四种上手方式

  • kind：Kubernetes SIG Testing 的官方工具，可在 rootless Docker、rootless nerdctl 或 rootless Podman 之上直接创建集群，一条 kind create cluster 即可
  • minikube：先执行 Docker 的 rootless 安装脚本，再 minikube start --driver docker
  • Usernetes：第三方 rootless Kubernetes 发行版（即该特性的发源地），支持用 VXLAN 加 Flannel 网络组建多节点集群
  • k3s：CNCF Sandbox 项目，rootless 模式不依赖外部容器运行时，适合轻量环境

下一步规划

官方计划根据社区反馈与采用情况，在未来版本把该特性推进到 GA（正式可用）。社区正在讨论的 KEP-5474（无特权容器可写 cgroups）与 KEP-5714（cgroup 命名空间）两项增强提案（KEP 即 Kubernetes 增强提案，是社区功能设计的正式文档），目标都是进一步简化 Kubernetes-in-Kubernetes 的搭建。

rootless 模式的本质是权限最小化：把节点组件从 root 降级为普通用户，让容器逃逸攻击的爆炸半径大幅缩小。Kubernetes 在 v1.37 将其默认启用，说明这项安全特性已进入成熟期；对集群管理员而言，值得在评估驱动兼容性之后，把它纳入生产集群的安全规划。