Kubernetes 1.37 fait passer le mode rootless en bêta

Kubernetes v1.37 fait passer le feature gate KubeletInUserNamespace en bêta. Une fois activé, chaque composant du nœud peut tourner sous un utilisateur ordinaire plutôt que root. Akihiro Suda, de NTT, a annoncé le changement sur le blog Kubernetes le 4 septembre 2026. La version v1.37.0 elle-même est sortie le 26 août 2026.

L'objectif est de limiter les dégâts. Si quelqu'un s'échappe d'un conteneur, il atterrit dans un compte sans privilèges, et non en root sur la machine.

Ce qui tourne vraiment sans root

Suda énumère quatre types de composants de nœud couverts par la fonction :

• le kubelet
• les runtimes de conteneurs CRI et OCI
• les plugins réseau CNI
• kube-proxy

Tous "can run as a non-root user on the host, using a Linux user namespace", écrit-il. "This technique is also known as rootless mode."

Un espace de noms utilisateur est une fonction du noyau Linux. Un processus s'y croit root, tandis que l'hôte continue de le traiter en utilisateur ordinaire. Les privilèges sont réels à l'intérieur et absents à l'extérieur.

C'est tout l'argument de sécurité. Suda formule la motivation sans détour : les composants du nœud ont "historically had container-breakout vulnerabilities that could compromise full root privileges on the host." Son billet en cite cinq.

• CVE-2022-0811
• CVE-2023-27561
• CVE-2024-10220
• CVE-2025-31133
• CVE-2026-53488

En mode rootless, une évasion par l'une de ces failles atteint un compte utilisateur normal. Elle n'atteint pas le root de l'hôte.

La distinction que beaucoup rateront

Il existe deux fonctions différentes d'espaces de noms utilisateur dans Kubernetes, et on les confond facilement.

Suda trace lui-même la ligne. Le mode rootless "should not be confused with user namespaces for pods", écrit-il. Cette autre fonction s'active avec hostUsers: false et le feature gate UserNamespacesSupport. Elle est disponible en version générale depuis la v1.36. Elle "puts pods in user namespaces but still runs the node components as root."

L'une place donc vos charges de travail dans un espace de noms. L'autre y place la machinerie. Elles résolvent deux moitiés du même problème, et le billet indique qu'on peut les combiner.

Sept ans de l'expérience à la bêta

Cette fonction a avancé lentement, et les dates en disent long sur sa difficulté.

Étape	Date
Première expérience	2018
Alpha, sous KEP-2033	v1.22, en 2021
Bêta	v1.37, en 2026

Cinq ans séparent l'alpha de la bêta. Faire tourner le kubelet sans root touche à la fois aux runtimes de conteneurs, aux plugins réseau et à la gestion des cgroups, et chacun a dû développer sa propre prise en charge.

Un KEP est un Kubernetes Enhancement Proposal, le document de conception écrit par lequel un tel changement doit passer. C'est la même forme de processus que GNOME est en train de rédiger pour lui-même.

Ce que cela signifie pour les développeurs

Vérifiez d'abord qui fait tourner votre kubelet. Si vous utilisez un service managé comme EKS, GKE ou AKS, ce processus ne vous appartient pas, et vous ne pouvez pas activer cette fonction. Elle compte surtout pour ceux qui gèrent leurs propres nœuds, montent un cluster de test ou déploient en périphérie.

Lisez l'annonce et ses prérequis avant d'essayer. Le mode rootless s'appuie sur des comportements précis du noyau, des versions précises de runtime et la délégation de cgroups, et le billet de Suda est l'endroit où ces détails figurent. Ne supposez pas que votre image de nœud actuelle convient.

Traitez la bêta comme une bêta. Chez Kubernetes, cela veut dire que la forme de l'API est à peu près fixée mais que les bords opérationnels ne le sont pas, et que les feature gates peuvent encore changer de valeur par défaut d'une version à l'autre. Faites tourner cela là où une perte reste acceptable.

L'enseignement utile tient même si vous n'activez jamais rien. Demandez-vous ce qu'une évasion de conteneur atteint réellement sur vos nœuds aujourd'hui. Pour la plupart des clusters, la réponse honnête est le root de l'hôte, et cette réponse devient un choix plutôt qu'une fatalité.