The post has been translated automatically. Original language: Russian
On September 4, 2026, an entry was posted on the official Kubernetes blog stating that the KubeletInUserNamespace capability flag moved from alpha to beta in version 1.37. We are talking about the so-called rootless mode: all node components of the cluster do not work from the superuser of the host, but from a regular account placed in the Linux user namespace. The opportunity has a long history — the experiment began in 2018, the code got into alpha in version 1.22 in 2021, and only now, five years later, the developers have found it suitable for widespread testing.
What exactly works without superuser rights
When the flag is enabled, four node layers are launched from an unprivileged user at once: kubelet itself, the implementation of the container runtime interface along with OCI runtime, CNI network plugins and kube proxy. That is, it is not a single process that becomes unprivileged, but the entire chain, which usually holds root rights on the node.
The point of the change is to limit the consequences. If a defect is found in the runtime environment or in kubelet that allows the process to break out of the container, in a normal configuration, the attacker gets root on the node with all the consequences: access to other people's containers, to secrets mounted on this node, to the network configuration. In rootless mode, the same defect only results in obtaining the rights of one unprivileged account. The blog entry lists five real defects in recent years for which such a distinction would work as insurance: sysctl processing in CRI-O, hidden paths and writing to procfs in runc, gitRepo volumes in kubelet, and code execution via tags in containerd.
How is this different from pod namespaces?
It's easy to confuse two different things here. User namespaces for pods are the hostUsers field with the value false and a separate UserNamespacesSupport flag, which became publicly available back in version 1.36: pods are placed in the namespace, and the node components still work from root.
KubeletInUserNamespace solves the opposite problem — the node itself leaves for the namespace. The capabilities do not compete, but add up: their combination allows you to run Kubernetes inside Kubernetes without giving the external pod full privileged mode. For CI test clusters, this significantly reduces the amount of rights granted.
What is required from the node
The requirements are specific: a Linux kernel with support for user namespaces and necessarily cgroup of the second version — the mode is not supported at all on the first version. The container runtime should also be able to run without root privileges, and the OCI runtime version should be compatible. Everything is enabled by the kubelet feature flag. For testing, the record mentions ready-made kind assemblies and the Usernetes project.
What does this mean in practice?
Beta is not an invitation to immediately transfer productive clusters, but an excuse to put the mode into plans and start testing on the test circuit.
What to look at in advance. The first is the node version of cgroup: the first one is still found on older distributions and in homemade images, and this is a blocking condition, not a minor setup. The second is the network layer: without root rights, part of the network operations on the host are unavailable, so it's not the pod operation that needs to be checked at all, but specifically your CNI plugin and services that need low port numbers. The third is privileged loads: metric collection agents, storage drivers, and everything that mounts node devices behave differently in an unprivileged environment, and such pods will have to be inventoried separately.
From operational experience, changing the rights model reveals not what is described in the documentation, but what has been held for years on an implicitly accessible root. Therefore, you should start with the most integration—rich test platform - it will show the list of incompatibilities more honestly.
The draft text was prepared with the participation of AI, the facts are checked against the original source — the official blog of the Kubernetes project
4 сентября 2026 года в официальном блоге Kubernetes вышла запись о том, что флаг возможностей KubeletInUserNamespace в версии 1.37 перешёл из альфы в бету. Речь о так называемом режиме rootless: все узловые компоненты кластера работают не от суперпользователя хоста, а от обычной учётной записи, помещённой в пользовательское пространство имён Linux. История у возможности длинная — эксперимент начался в 2018 году, в альфу код попал в версии 1.22 в 2021-м, и только теперь, спустя пять лет, разработчики сочли его пригодным к широкой обкатке.
Что именно работает без прав суперпользователя
Когда флаг включён, от непривилегированного пользователя запускаются сразу четыре слоя узла: сам kubelet, реализация интерфейса среды выполнения контейнеров вместе с OCI-рантаймом, сетевые плагины CNI и kube-proxy. То есть непривилегированным становится не отдельный процесс, а вся цепочка, которая на узле обычно и держит права root.
Смысл изменения — в ограничении последствий. Если в среде выполнения или в kubelet находят дефект, позволяющий процессу вырваться за границы контейнера, в обычной конфигурации атакующий получает root на узле со всеми вытекающими: доступ к чужим контейнерам, к секретам, смонтированным на этом узле, к сетевой конфигурации. В режиме rootless тот же самый дефект приводит лишь к получению прав одной непривилегированной учётной записи. В записи блога перечислены пять реальных дефектов последних лет, для которых такое разграничение сработало бы страховкой: обработка sysctl в CRI-O, скрытые пути и запись в procfs в runc, тома типа gitRepo у kubelet и выполнение кода через метки в containerd.
Чем это отличается от пространств имён для подов
Здесь легко перепутать две разные вещи. Пользовательские пространства имён для подов — это поле hostUsers со значением false и отдельный флаг UserNamespacesSupport, ставший общедоступным ещё в версии 1.36: в пространство имён помещаются поды, а компоненты узла по-прежнему работают от root.
KubeletInUserNamespace решает обратную задачу — в пространство имён уезжает сам узел. Возможности не конкурируют, а складываются: их сочетание позволяет запускать Kubernetes внутри Kubernetes, не выдавая внешнему поду полный привилегированный режим. Для тестовых кластеров в CI это заметно снижает объём выданных прав.
Что требуется от узла
Требования конкретные: ядро Linux с поддержкой пользовательских пространств имён и обязательно cgroup второй версии — на первой версии режим не поддерживается вовсе. Среда выполнения контейнеров тоже должна уметь работать без прав root, а версия OCI-рантайма — быть совместимой. Включается всё флагом возможностей у kubelet. Для пробы в записи упоминаются готовые сборки kind и проект Usernetes.
Что это значит на практике
Бета — это не приглашение немедленно переводить продуктивные кластеры, а повод закладывать режим в планы и начинать проверки на тестовом контуре.
На что посмотреть заранее. Первое — версия cgroup на узлах: на старых дистрибутивах и в самодельных образах до сих пор встречается первая, и это блокирующее условие, а не мелочь настройки. Второе — сетевой слой: без прав root часть операций с сетью на хосте недоступна, поэтому проверять надо не работу подов вообще, а конкретно ваш плагин CNI и сервисы, которым нужны низкие номера портов. Третье — привилегированные нагрузки: агенты сбора метрик, драйверы хранилищ и всё, что монтирует устройства узла, в непривилегированном окружении ведёт себя иначе, и такие поды придётся инвентаризировать отдельно.
По опыту эксплуатации смена модели прав вскрывает не то, что описано в документации, а то, что годами держалось на неявно доступном root. Поэтому начинать стоит с самой насыщенной интеграциями тестовой площадки — она честнее покажет список несовместимостей.
Черновик текста подготовлен с участием ИИ, факты сверены с первоисточником — официальный блог проекта Kubernetes
Share
