UserNamespaces dans Kubernetes : la feature géniale qui sert (presque) à rien

Tue, 28 Apr 2026 10:00:00 +0200

L’infographie qui m’a trigger

Depuis quelques jours, les infographies se suivent (et se ressemblent) sur Linkedin. Kubernetes 1.36 est sorti et une des features qui fait le plus parler, c’est la sortie en GA des UserNamespaces.

C’est un sujet que je suis depuis 2018 (talk The Route to rootless container à la kubecon EU de 2018) donc je peux dire que je suis content de voir l’aboutissement de ce long chemin. Cependant, je suis “profondément choqué” de voir la façon dont c’est présenté sur LinkedIn, visiblement par des gens qui n’ont aucune idée de comment ça fonctionne (et qui probablement, s’en fichent).

“Kubernetes just made root safer. Just add hostUsers: false to your Pod spec.”

Le visuel : un roi tout-puissant “inside the container” et un mendiant impuissant “outside on the host”. La promesse : “No Host Access. No Privilege Escalation. No Lateral Movement. No Node Takeover.”

C’est accrocheur.

Mais c’est surtout hyper grave de le présenter comme ça, parce que ça occulte des pans entiers de sécurité applicative et opérationnelle. Vendre hostUsers: false comme le remède universel au problème du “root dans les containers”, c’est une simplification dramatique qui va pousser des équipes à ignorer les vraies priorités de sécurité.

Ce que les UserNamespaces font réellement, sans bullshit

Le threat model : le container escape

Avant tout, de quoi parle-t-on exactement ? Un container escape (évasion de container), c’est quand un attaquant réussit à sortir de son container et à accéder directement au kernel ou au système de fichiers de l’hôte, en bypassant complètement les mécanismes d’isolation habituels.

Ce type de vulnérabilité est rare, mais des exemples bien réels existent :

CVE-2019-5736 (runc) : écriture dans /proc/self/exe du process hôte depuis le container
CVE-2022-0492 (cgroups v1) : escape via unshare dans certaines configurations
CVE-2024-21626 (runc, “Leaky Vessels”) : fuite de file descriptor vers le répertoire de travail de l’hôte

S’il y a une faille de ce type sur votre Node ET qu’un process est compromis ET s’il tourne en root dans le container ET qu’il n’a pas les UserNamespaces, l’attaquant obtient root sur l’hôte, c’est game over. Accès à tous les fichiers du Node, à tous les secrets montés par les autres pods, possibilité d’installer un rootkit ou d’exfiltrer les données de tous les tenants présents sur le Node.

Ca reste possible, mais ça fait beaucoup de “si”. Quoiqu’il en soit, c’est exactement ce scénario que les UserNamespaces adressent. Ils introduisent un mapping d’UID :

L’UID 0 dans le container est mappé vers un UID non-privilégié sur l’hôte (ex: 100000, propre à chaque pod)
Si un attaquant réussit à s’échapper du container via un exploit kernel, il se retrouve nobody sur le node, l’escape réussit, mais l’impact post-escape est dramatiquement réduit

C’est le scénario “Breakouts Lose Impact” de l’infographie, et là-dessus, l’infographie dit vrai. C’est le vrai apport de la feature.

Cas particulier : le multi-tenant même en non-root

Même sans container root, les UserNamespaces apportent aussi quelque chose dans un contexte vraiment multi-tenant (plusieurs clients différents sur le même cluster). Sans UserNamespaces, si deux pods de clients différents tournent tous les deux avec runAsUser: 1000, ils partagent le même UID 1000 sur le node. En cas d’escape sur l’un, l’attaquant peut accéder aux fichiers de l’autre pod qui ont le même propriétaire. Le mapping UID de UserNamespaces, en donnant un offset unique à chaque pod, isole les UID entre pods même à valeur identique dans le container.

Pour les clusters internes où vous contrôlez tous les workloads, ce scénario est théorique. Pour une plateforme SaaS multi-tenant ou un service de build public, c’est une vraie ligne de défense.

Prérequis techniques

Pour pouvoir bénéficier de cette feature, il y a quelques prérequis, mais la majorité des clusters à jour devraient pouvoir se qualifier.

Kernel Linux ≥ 5.19
Runtime compatible (containerd ≥ 1.7, CRI-O ≥ 1.25)
Support des idmapped mounts pour les volumes persistants (XFS, ext4, mais pas NFS dans tous les cas par exemple)
Kubernetes ≥ 1.33 (Beta), ≥ 1.36 (GA)

Ce que l’infographie exagère (et ce qu’elle oublie)

L’infographie a donc raison sur un point précis : UserNamespaces réduit l’impact d’un container escape réussi. C’est réel. Le problème, c’est qu’elle vend la feature comme solution universelle au “root dans les containers”, et là c’est n’importe quoi.

1. L’isolation de l’UID n’est pas une isolation des privilèges applicatifs

L’infographie promet “No Lateral Movement”. C’est faux (et archi faux).

Un container root avec hostUsers: false peut toujours lire le ServiceAccount Token monté dans /var/run/secrets/kubernetes.io/serviceaccount/token. Si ce token a des permissions RBAC étendues (ce qui arrive, on en reparlera peut être dans un autre article prochainement), l’attaquant peut appeler l’API Server, énumérer les ressources du cluster, et se déplacer latéralement, le tout sans jamais toucher le Node hôte.

Le mapping d’UID protège l’hôte. Il ne protège pas le cluster.

2. Un container root reste root dans le container

“Install Anything ✅” — c’est littéralement écrit dans l’infographie, présenté comme un avantage 😖.

Dans un container root (même avec UserNS), un attaquant qui prend la main peut :

Installer nmap, curl, nc pour scanner le réseau interne
Modifier les fichiers de l’application, les binaires, les configurations
Lire tous les fichiers montés en volume
Persister dans le container entre les redémarrages si le filesystem est writable

Les UserNamespaces ne retirent aucun de ces vecteurs d’attaque. Pouvoir ajouter des logiciels, c’est la garantie d’un mouvement latéral rapide (là encore).

3. C’est pas si facile, surtout pour le sto

Activer hostUsers: false casse le stockage existant dans la plupart des cas.

L’UID 0 du container est mappé sur l’UID 100000+ sur l’hôte (chaque container a son propre “offset”). Si un volume persistant (NFS, EBS, Ceph RBD) appartient à l’UID 1000, le container root ne peut ni lire ni écrire dessus. Le résultat : des Permission Denied contre intuitifs, potentiellement complexes à diagnostiquer car l’application n’a probablement pas été conçue, si elle est root, pour ne pas avoir accès à ses propres fichiers.

La solution technique existe (idmapped mounts), mais elle nécessite un kernel récent et un filesystem compatible. Voir la documentation officielle des idmapped mounts pour les détails.

4. Idem, mais pour le réseau

hostUsers: false est incompatible avec hostNetwork: true. C’est un détail, mais il piège les workloads réseau (agents de monitoring, CNI plugins, etc.).

Note : cela dit, avoir des containers en hostNetwork est un autre souci de sécurité, donc bon…

Comparaison sans bullshit : UserNS vs les alternatives existantes

Vecteur d’attaque	UserNS (root inside)	Non-root (UID 1000)	Distroless / Scratch
Impact post-escape si container escape réussi	✅ Nobody sur l’hôte	⚠️ UID 1000 sur l’hôte	⚠️ UID 1000 sur l’hôte
Isolation UID entre pods (multi-tenant)	✅ Offset unique par pod	❌ UID partagé sur le node	❌ UID partagé sur le node
Installation de malwares dans le container	❌ Facile	⚠️ Difficile	✅ Quasi impossible
Persistance dans le container	❌ Totale	⚠️ Limitée	✅ Quasi impossible
Mouvement latéral via SA Token	❌ Possible	❌ Possible	⚠️ Potentiellement difficile
Complexité opérationnelle	❌ Parfois élevée	✅ Souvent quasi nulle	✅ Souvent faible
Compatibilité stockage existant	❌ Parfois problématique	✅ Standard	✅ Standard

La lecture de la table révèle la vraie nature d’UserNamespaces, il excelle sur exactement deux lignes :

l’impact post-escape
l’isolation UID en multi-tenant.

Sur tout le reste, non-root + distroless fait mieux, ou aussi bien, sans la complexité opérationnelle. Et ce sont ces “tout le reste” (persistance, installation de malwares, mouvement latéral via SA Token) qui représentent la grande majorité des vecteurs d’attaque réels, bien plus fréquents qu’un container escape. On en reparlera dans la section Où investir son budget sécurité.

Les vrais cas d’usage

Ce serait malhonnête de tout rejeter. Il existe trois scénarios où les UserNamespaces ne sont pas une option “fainéante” mais une nécessité technique (et encore, ça se discute).

1. Build-as-a-Service (Buildah, rootless Podman)

Pour construire une image Docker, le moteur de build doit pouvoir faire des chown, chmod et mknod. Ces opérations nécessitent CAP_CHOWN et CAP_FOWNER. Avant les UserNamespaces, la solution était de lancer le pod en --privileged, ce qui est évidemment une porte ouverte sur l’hôte.

Avec hostUsers: false, le moteur de build a l’illusion d’être root pour manipuler ses fichiers, mais il est incapable d’impacter l’hôte. C’est le seul cas où “root inside” est une contrainte technique et non de la dette.

Note : Kaniko, longtemps la référence pour le build in-cluster, est archivé depuis juin 2025 et ne reçoit plus de mises à jour de sécurité. Buildah ou rootless Podman sont les alternatives actives.

Mon avis : ça peut être éventuellement utile pour les plateformes CI/CD mutualisées (GitLab Runners, Tekton) qui refusent les pods privilégiés. Mais si l’isolation est critique (plateforme publique, multi-tenant agressif), les microVMs (Kata Containers, Firecracker) offrent une garantie bien supérieure pour un overhead devenu raisonnable.

2. Multi-tenancy hostile (plateformes de code utilisateur)

Si votre métier est de faire tourner du code fourni par des inconnus (PaaS, éditeur de code en ligne, CI/CD publique), vous savez d’avance que l’utilisateur va essayer d’escalader ses privilèges. Dans ce contexte, l’UserNS est une barrière supplémentaire contre les 0-day kernel.

Mon avis : honnêtement, si l’environnement est vraiment hostile, l’UserNS seul n’est pas suffisant. Les microVMs (Kata Containers, Firecracker) offrent une isolation matérielle réelle et sont le choix correct pour ce cas. L’UserNS peut être un complément, pas un substitut.

3. Legacy “hard-coded” (Postfix, Dovecot, BIND)

Certains vieux démons UNIX démarrent en root pour ouvrir un port < 1024 ou lire des fichiers de config sensibles, puis “drop” leurs privilèges via setuid(). Ce mécanisme échoue dans un container non-root classique.

Les UserNamespaces permettent à ces processus de croire qu’ils peuvent faire leurs appels système de gestion d’identité, car ils sont root dans leur namespace.

Voici un exemple concret écrit par un collègue (thanks Louis 😘) :

apiVersion: v1
kind: Pod
metadata:
 name: postfix
spec:
 hostUsers: false # mapping UID : root dans le container → nobody sur l'hôte
 securityContext:
 runAsNonRoot: false # autorisé en PSS Restricted *uniquement* grâce à hostUsers: false
 fsGroup: 103 # GID postfix
 containers:
 - name: postfix
 image: postfix:latest
 securityContext:
 runAsNonRoot: false # idem, cf. https://kubernetes.io/docs/concepts/workloads/pods/user-namespaces/#integration-with-pod-security-admission-checks
 allowPrivilegeEscalation: false
 readOnlyRootFilesystem: true
 seccompProfile:
 type: RuntimeDefault
 capabilities:
 drop: ["ALL"] # d'abord, on drop tout
 add:
 - SETUID  # on ajoute SETUID mais le drop de privilèges via setuid() 
 # est fait par postfix lui-même au démarrage 
 - SETGID  # idem pour les groupes
 - CHOWN  # chown sur les queues au démarrage
 - FOWNER  # opérations sur fichiers sans être propriétaire
 - FSETID  # conserver le setuid bit après écriture
 - DAC_OVERRIDE # OBLIGATOIRE : root dans UserNS n'est pas "vrai" root,
 # les vérifications DAC ne sont pas contournées automatiquement

Ce manifest illustre plusieurs choses importantes.

D’abord, c’est très pénible de rendre une application legacy secure avec les UserNS, et il faut faire des compromis, notamment sur les capabilities (on est loin de la feature magique qui sécurise les apps root).

Ensuite, on remarque des trucs rigolos. Normalement, la policy Restricted (Pod Security Standard) interdit runAsNonRoot: false. Kubernetes fait une exception quand hostUsers: false est présent. C’est documenté ici. Sans UserNamespaces, ce pod serait rejeté par l’admission controller.

De plus, on doit ajouter la capacité DAC_OVERRIDE, ce qui est contre-intuitif. root dans un UserNS n’est pas un vrai root du point de vue du kernel pour les vérifications DAC (Discretionary Access Control). Quand Postfix essaie de faire set-permissions pour chown ses queues, le kernel vérifie quand même les permissions ; et les refuse si DAC_OVERRIDE n’est pas là. C’est exactement le genre de surprise opérationnelle invisible jusqu’au premier déploiement en production.

On notera malgré tout qu’on a pu garder readOnlyRootFilesystem: true et allowPrivilegeEscalation: false ; le legacy ne justifie pas de tout sacrifier.

Mon avis : c’est le seul cas d’usage où l’UserNS est vraiment acceptable. Pas de code tiers non maîtrisé, pas de plateforme hostile, juste du legacy bien identifié avec un plan de migration ultérieur. Les deux autres cas sont “acceptables sous conditions”, le legacy reste le plus propre des trois.

Quelques contre-arguments

Je vous vois arriver avec quelques contre arguments, donc pour gagner du temps à tout le monde, je vais faire les questions et les réponses :

“C’est de la défense en profondeur.” “Vrai, mais”… La défense en profondeur suppose qu’on a déjà posé les couches de base. Si vous n’avez pas encore migré vos images vers un user non-root, mettre de l’énergie sur l’UserNS est un non-sens. Et une fois en non-root, le gain marginal de l’UserNS est négligeable face à la complexité qu’il introduit.

“On ne contrôle pas les images tierces.” Argument un peu faible, à mon avis : si vous avez une image blackbox de votre éditeur propriétaire, qui est codée pour tourner en root, il y a de fortes chances :

soit qu’elle en ait réellement besoin pour fonctionner (typiquement, le cas pour certains outils de sécurité propriétaires)
soit qu’elle gère mal le mapping d’UID (cf. le problème de stockage). L’UserNS n’est pas une baguette magique qui rend n’importe quelle image tierce compatible et sécurisée.

“C’est un garde-fou contre les erreurs humaines.” Il est aussi facile d’oublier hostUsers: false que d’oublier runAsNonRoot: true. La vraie solution centralisée, ce sont les Pod Security Standards ou un Admission Controller (Kyverno, OPA) qui rejettent purement et simplement les pods root. C’est plus simple, plus fiable, et ça ne casse pas le stockage.

“On en a besoin pour la compliance SOC2/PCI-DSS/…” Si votre compliance exige une isolation stricte entre tenants, l’UserNS sera probablement jugé insuffisant par vos auditeurs. Les VMs ou microVMs restent le standard. Utiliser l’UserNS pour la compliance, c’est choisir l’outil le plus complexe à maintenir pour un résultat discutable.

Où investir son budget sécurité ?

Si on met de côté le marketing, voici où l’effort paye vraiment, du plus impactant au plus niche :

Priorité 1 — Images non-root + nobody (UID 65534) Passer les images en non-root, idéalement vers l’utilisateur nobody (le moins privilégié du système). Si une application est compromise sous nobody, l’attaquant ne peut pratiquement rien faire, même sur le filesystem du container. À combiner avec readOnlyRootFilesystem: true et capabilities: drop: ["ALL"].

spec:
 securityContext:
 runAsNonRoot: true
 runAsUser: 65534 # nobody
 seccompProfile:
 type: RuntimeDefault
 containers:
 - name: app
 image: my-app:distroless
 securityContext:
 allowPrivilegeEscalation: false
 capabilities:
 drop: ["ALL"]
 readOnlyRootFilesystem: true

Priorité 2 — Pod Security Standards (PSS) en mode Baseline ou Restricted Bloquer le root et les privilèges sans rien casser au niveau infra. Ça nécessite d’avoir déjà fait le point n°1, mais c’est gratuit, standard, et ça s’applique à tout le cluster via un label de namespace (et ça peut s’overrider par namespace si nécessaire). Plus de risque d’oubli possible. C’est déjà configuré par défaut sur plusieurs types de Kubernetes (je pense à Talos, mais ce n’est pas le seul).

Priorité 3 — MicroVMs (Kata Containers, Firecracker) Pour les workloads vraiment non-fiables. Isolation matérielle réelle, overhead devenu raisonnable sur les générations récentes.

Priorité 4 — UserNamespaces When all else fail. Uniquement pour les cas légitimes identifiés ci-dessus (build, legacy, multi-tenancy hostile). C’est vraiment littéralement la dernière chose à faire.

Conclusion

Les UserNamespaces dans Kubernetes 1.36 sont l’aboutissement d’un chantier qui aura pris “officiellement” cinq ans (KEP-127 date de 2021) et dont on parle quasiment depuis la genèse de Kubernetes. Pour les plateformes de build mutualisées et les SaaS multi-tenants qui font tourner du code utilisateur, c’est une brique potentiellement intéressante (notamment pour éviter qu’une app d’un client lise les apps d’un autre en cas de container escape sans élévation de privilège).

Pour le reste (c’est-à-dire 99% des clusters de production) c’est une distraction.

Les infographies LinkedIn qui vendent une sécurité sans effort sont dangereuses : “gardez votre image root de 800 Mo pleine d’outils, ajoutez juste hostUsers: false, et vous êtes protégés”. C’est exactement l’inverse de la bonne démarche. La vraie sécurité container se construit dans le Dockerfile, pas dans le PodSpec.

Si vous activez les UserNamespaces pour sécuriser une application dont vous possédez le code source, vous avez probablement raté une étape dans votre cycle de développement sécurisé.

Références

KEP-127 : Support for User Namespaces
Kubernetes docs — User Namespaces
Pod Security Standards
CVE-2019-5736 — runc : écriture dans /proc/self/exe du process hôte depuis le container
CVE-2022-0492 — cgroups v1 : escape via unshare, UserNS aide mais runAsNonRoot aussi
CVE-2024-21626 — runc “Leaky Vessels” : fuite de file descriptor vers le répertoire de travail de l’hôte
Distroless containers — GoogleContainerTools

Rbac on Zwindler's Reflection