Kubernetes 1.37 passe le mode rootless en bêta pour les composants du nœud
La version 1.37 de Kubernetes active par défaut KubeletInUserNamespace : kubelet, runtimes et CNI peuvent désormais tourner en tant que non-root dans un user namespace. Activez-le sur vos nœuds pour confiner les failles de type container-breakout loin des privilèges root de l’hôte.
4 septembre 2026. Kubernetes v1.37 promeut au statut bêta la fonctionnalité KubeletInUserNamespace, dite mode rootless, désormais activée par défaut. Le travail, démarré comme expérience en 2018 puis fusionné en alpha dans v1.22 (2021) via la KEP-2033, arrive à maturité. Pourquoi c’est important : les composants du nœud ont historiquement accumulé des failles de container-breakout qui donnaient le root complet de l’hôte. Le mode rootless réduit le rayon de dégâts de ces failles à un simple compte non-root.
Le nœud tourne enfin sans root
Avec la fonctionnalité activée, tous les composants du nœud — kubelet, les runtimes CRI et OCI, les plugins CNI et kube-proxy — s’exécutent en tant qu’utilisateur non-root sur l’hôte, à l’intérieur d’un user namespace Linux. C’est la définition exacte du mode rootless, popularisé par Docker et Podman.
Il ne faut pas confondre cette fonctionnalité avec les user namespaces pour les pods (hostUsers: false, via la fonctionnalité UserNamespacesSupport, GA depuis v1.36), qui placent les pods dans des user namespaces mais laissent les composants du nœud tourner en root. Les deux ne sont pas en conflit : on peut même les combiner pour imbriquer Kubernetes dans Kubernetes sans recourir au privileged: true.
Comment ça marche sous le capot
Un user namespace Linux projette un UID non-root de l’hôte — par exemple 1000 — vers un faux root (UID 0) à l’intérieur du namespace. Les privilèges du UID 0 sont alors confinés à l’intérieur du namespace : ce faux root suffit à l’essentiel des tâches du nœud — monter des volumes, créer des cgroups, configurer les namespaces réseau des pods — mais il n’a aucune autorité sur l’hôte.
Le namespace doit être créé en dehors de Kubernetes, par exemple avec Docker rootless, Podman rootless ou nerdctl. La gate KubeletInUserNamespace elle-même reste volontairement « ennuyeuse » : elle fait surtout ignorer au kubelet les erreurs de permission lors de la définition de certains sysctls — comme vm.overcommit_memory ou kernel.panic — et lors de la lecture de /dev/kmsg.
Cette sobriété est le signe d’un bon design. La fonctionnalité ne réécrit pas le kubelet : elle le rend compatible avec un environnement non-root déjà provisionné, ce qui limite la surface de régression.
Pourquoi maintenant : l’historique des évasions
La motivation tient en une liste de CVE qui ont toutes abouti à une exécution de code en root sur l’hôte :
- CVE-2022-0811 (« cr8escape ») : CRI-O pouvait être piégé pour définir des sysctls arbitraires comme
kernel.core_pattern, aboutissant à une exécution de code en root. - CVE-2023-27561 : runc pouvait contourner les chemins masqués via une course sur le montage de volume, exposant les fichiers procfs de l’hôte (régression de CVE-2019-19921).
- CVE-2024-10220 : le kubelet pouvait exécuter des commandes arbitraires en root via les volumes gitRepo (une faille similaire, CVE-2018-11235, datait de 2018).
- CVE-2025-31133 : runc pouvait monter des chemins contrôlés par l’attaquant et écrire dans les fichiers procfs, comme
/proc/sysrq-trigger. - CVE-2026-53488 : containerd pouvait exécuter des commandes sur l’hôte via des labels forgés dans une image de conteneur.
En exécutant les composants du nœud dans un user namespace, les dégâts potentiels sont confinés au compte non-root. Un attaquant ne peut notamment plus dissimuler son intrusion en modifiant le noyau, le chargeur d’amorçage ou le firmware.
Une limite à connaître : les user namespaces ne neutralisent pas les vulnérabilités du noyau lui-même. Il faut les combiner avec les durcissements classiques, comme seccomp pour empêcher l’invocation d’appels système superflus.
Le rootless s’inscrit donc dans une défense en profondeur, pas dans une promesse d’isolation totale. Pour des charges réellement hostiles — du code non fiable exécuté en production — il faut l’empiler avec des sandboxes de runtime comme gVisor ou Kata Containers, qui interposent une frontière plus forte entre le workload et le noyau. Le rootless réduit le coût d’une faille du nœud ; il ne remplace ni la segmentation des charges ni la politique réseau.
Ce qui change entre l’alpha et la bêta
La bascule vers la bêta est volontairement discrète, et c’est une bonne chose. La gate est désormais activée par défaut, mais l’activer ne place pas le kubelet dans un user namespace automatiquement : rien ne change pour les clusters « rootful » existants.
kubectl get nodes -o yaml rapporte maintenant si un nœud tourne dans un user namespace, via la propriété runningInUserNamespace. Un administrateur peut s’en servir pour poser des labels ou des taints, afin d’éviter d’ordonnancer sur des nœuds rootless des charges qui exigent le vrai root — par exemple certains installeurs de plugins CNI.
Côté qualité, les tests de conformité de bout en bout tournent désormais sur un cluster rootless (ci-kubernetes-e2e-kind-rootless), ce qui ancre la fonctionnalité dans le cycle de validation du projet.
Cas d’usage concrets
Le rootless couvre un spectre plus large que la seule production. Sur des machines partagées — un cluster HPC par exemple — des utilisateurs peuvent déployer Kubernetes sans demander les privilèges root à l’administrateur, et sans risquer de casser l’environnement des autres. Sur un portable, un cluster local rootless ne peut plus endommager la configuration de l’hôte, comme les règles iptables utilisées par un VPN.
Deux usages émergents méritent l’attention. D’abord le bac à sable IA : un développeur peut créer un compte local dédié pour faire tourner un agent de codage et un cluster de test, empêchant l’agent abusé par du contenu malveillant de compromettre l’hôte. Ensuite le bootstrapping : un cluster non privilégié temporaire peut amorcer un vrai cluster, par exemple avec Cluster API.
Comment l’utiliser
La voie la plus simple passe par kind, qui sait lancer un cluster dans Docker rootless, nerdctl rootless ou Podman rootless :
dockerd-rootless-setuptool.sh install
kind create clusterminikube supporte aussi le mode rootless via Docker ou Podman rootless, tout comme k3s, qui ne dépend d’aucun runtime externe. Pour les déploiements multi-nœuds, Usernetes — maintenu par l’auteur de la fonctionnalité, Akihiro Suda — relie plusieurs nœuds rootless via VXLAN et le plugin Flannel.
Le rootless n’arrive pas seul. Plusieurs améliorations l’ont rendu viable en amont : le noyau Linux 6.3 (2023) a ajouté le support du tmpfs idmapped, Kubernetes v1.33 (2025) a activé UserNamespacesSupport par défaut, et containerd v2.1 (2025) a ajouté les cgroups inscriptibles. Grâce à elles, un cluster avec KubeletInUserNamespace peut désormais être imbriqué dans des pods hostUsers: false.
Verdict
Si vous opérez un cluster de production, activez KubeletInUserNamespace sur les nœuds dont la CNI et la CSI le tolèrent : c’est la réduction de surface d’attaque la plus rentable face à la classe des failles container-breakout, pour un coût de migration proche de zéro puisque la gate n’altère pas les clusters existants.
Si vous faites tourner des machines partagées (HPC) ou des clusters de développement sur poste, remplacez vos clusters « rootful » par kind, minikube ou k3s en mode rootless : vous éliminez une classe entière de compromission root de l’hôte, y compris quand un agent IA local se fait abuser par du contenu malveillant.
Si votre charge exige le vrai root (certains installeurs CNI, accès direct aux devices), gardez-la sur des nœuds dédiés et taints, et confine tout le reste en rootless.