Kubernetes v1.33 active les espaces de noms utilisateur par défaut pour une meilleure isolation

Dans un article publié sur le blog Kubernetes en avril 2025, les mainteneurs ont annoncé que Kubernetes v1.33 active la prise en charge des espaces de noms utilisateur Linux par défaut. Cette modification permet aux pods d'opter pour une isolation plus forte sans nécessiter de drapeaux de fonctionnalité (feature flags), à condition que l'infrastructure sous-jacente réponde à des exigences spécifiques en matière de noyau et d'environnement d'exécution.

Ce qui s'est passé

Avant cette version, l'utilisation des espaces de noms utilisateur dans Kubernetes exigeait l'activation explicite de portes de fonctionnalité (feature gates) et la navigation dans des étapes de configuration complexes. Avec la version 1.33, la fonctionnalité est stable et activée par défaut. Lorsque les exigences de la pile technologique sont satisfaites, les utilisateurs peuvent simplement opter pour cette fonctionnalité via les spécifications des pods. Ce changement marque une étape significative vers une orchestration de conteneurs sécurisée par défaut, réduisant les frictions associées à la mise en œuvre de modèles de sécurité du moindre privilège.

L'annonce précise qu'il s'agit d'une fonctionnalité exclusive à Linux. Elle distingue les espaces de noms utilisateur Linux, qui isolent les identifiants utilisateur au niveau du noyau, des namespaces Kubernetes, qui sont des regroupements logiques de ressources. La mise à jour vise à atténuer les risques associés aux évasions de conteneurs en garantissant que les processus exécutés en tant que root à l'intérieur d'un conteneur ne détiennent pas de privilèges root sur le nœud hôte.

Comment cela fonctionne

Les espaces de noms utilisateur Linux isolent les User IDs (UIDs) et Group IDs (GIDs) des processus à l'intérieur d'un conteneur de ceux présents sur le système hôte. Lorsqu'un pod utilise un espace de noms utilisateur, les UIDs et GIDs à l'intérieur du conteneur sont mappés vers des identifiants différents et non privilégiés sur l'hôte. Par exemple, un processus exécuté avec l'UID 0 (root) à l'intérieur du conteneur peut être mappé vers l'UID 100000 sur l'hôte. Ce mapping garantit que, même si un processus de conteneur franchit ses limites, il ne dispose pas des permissions nécessaires pour modifier les fichiers de l'hôte ou interagir avec d'autres processus hôtes en tant qu'utilisateur privilégié.

Ce mécanisme repose fortement sur les « idmap mounts », une fonctionnalité du noyau Linux qui applique les mappings UID/GID lors de l'accès aux systèmes de fichiers montés. Les idmap mounts permettent à chaque pod d'utiliser des UIDs distincts sur l'hôte sans nécessiter de modifications manuelles de la propriété des fichiers (chown) sur les volumes. Cela simplifie la gestion des volumes et permet des fonctionnalités telles que le partage de volumes entre pods ayant des mappings d'utilisateurs différents. Cependant, les systèmes de fichiers utilisés pour les volumes doivent prendre en charge les idmap mounts. La plupart des systèmes de fichiers courants sont pris en charge, mais NFS est notablement absent des listes de support actuelles.

Détails clés

• Mécanisme d'opt-in : Les utilisateurs activent la fonctionnalité en définissant hostUsers: false dans la spécification du pod.
• Exigences du noyau : Une version du noyau Linux 6.3 ou supérieure est recommandée pour prendre en charge tmpfs pour les secrets et les config maps. Le noyau 5.19 est le minimum requis pour la prise en charge d'overlayfs.
• Compatibilité de l'environnement d'exécution : Containerd version 2.0 ou supérieure est requise. CRI-O fonctionne immédiatement. D'autres environnements d'exécution, y compris cri-dockerd, ne prennent actuellement pas en charge cette fonctionnalité avec Kubernetes.
• Avantages en matière de sécurité : Empêche les mouvements latéraux entre les conteneurs et garantit que les capacités accordées à l'intérieur de l'espace de noms sont invalides sur l'hôte.
• Limitations : Les applications nécessitant des privilèges directs sur l'hôte, telles que le chargement de modules du noyau, ne peuvent pas utiliser les espaces de noms utilisateur. Les volumes NFS ne sont pas pris en charge avec les idmap mounts.

Pourquoi c'est important

Pour les ingénieurs logiciels et les équipes de plateforme, cette mise à jour répond à un dilemme de sécurité de longue date : exécuter des applications en tant que root à l'intérieur des conteneurs pour des raisons de compatibilité tout en tentant de minimiser les risques sur l'hôte. Traditionnellement, l'exécution en tant que non-root nécessitait un refactoring significatif des applications ou des solutions personnalisées complexes pour gérer les permissions de fichiers. Les espaces de noms utilisateur permettent aux équipes d'exécuter des applications en tant que root en interne sans accorder de privilèges au niveau de l'hôte, découplant efficacement la logique applicative des contraintes de sécurité de l'infrastructure.

L'activation par défaut renforce également la défense contre les vulnérabilités d'évasion de conteneurs. Des CVE courantes, telles que CVE-2024-21626 et CVE-2022-0492, sont atténuées car les processus échappés ne conservent que des identités hôtes non privilégiées. Cela réduit la surface d'attaque pour les mouvements latéraux, où un conteneur compromis pourrait autrement accéder à des fichiers ou des processus appartenant à d'autres conteneurs sur le même nœud. En garantissant des UIDs hôtes uniques pour chaque pod, le kubelet impose une isolation qui était auparavant difficile à obtenir de manière cohérente.

Ce que vous pouvez faire

• Vérifiez vos nœuds pour assurer la conformité aux prérequis.
• Activez la fonctionnalité en définissant hostUsers: false dans les spécifications de vos pods.
• Assurez-vous que votre environnement d'exécution (Containerd >= 2.0 ou CRI-O) est compatible.
• Notez que les volumes NFS ne sont pas pris en charge avec cette configuration.