Espace de noms : Namespace
Infrastructure
Périmètre dans lequel un nom prend un sens local : deux objets portant le même nom dans deux espaces différents ne se confondent pas. Le même mécanisme sert tantôt à ranger, tantôt à isoler, et il faut savoir lequel des deux on a sous la main.
Noyau Linux : Huit types d'espaces (montage, PID, réseau, utilisateur, UTS, IPC, cgroup, temps) donnent à un processus sa propre vue du système : ses PID, ses interfaces réseau, ses points de montage. Un conteneur n'est au fond qu'un processus placé dans un jeu de ces espaces, complété par les cgroups pour limiter les ressources ; l'isolation est réelle et appliquée par le noyau.
Kubernetes : Découpage logique d'un cluster : un nom d'objet doit être unique dans son namespace, et c'est à ce niveau que s'accrochent les quotas (ResourceQuota, LimitRange) et les droits RBAC (Role, RoleBinding). Certains objets restent globaux au cluster, comme les nœuds ou les volumes persistants.
Pas une frontière : Par défaut, deux pods de namespaces Kubernetes différents se parlent sans entrave et partagent le noyau du même nœud ; l'isolation passe par des NetworkPolicy et des contrôles d'admission. Sans eux, ranger la prod et la recette dans deux namespaces revient à séparer deux équipes par une étiquette sur la porte d'un open space commun.
Code, XML, paquets : En programmation, un namespace C++ ou un module Python évite les collisions de noms entre bibliothèques ; en XML, un préfixe lié à une URI par xmlns distingue deux balises homonymes. Les registres de paquets font de même avec les scopes npm (@org/paquet) ou le groupId Maven.
Ce qui arrive si on s'en passe
Sans espace de noms, tous les noms partagent un périmètre unique : deux objets homonymes entrent en collision, le dernier défini masque ou écrase le premier, et la résolution d'un nom dépend de l'ordre de chargement plutôt que de l'intention. Lorsque le mécanisme sert à isoler (espaces de noms du noyau Linux, par exemple), son absence permet à un processus de voir les autres processus de l'hôte et de leur envoyer des signaux si ses droits l'y autorisent. Il partage aussi la pile réseau et ses ports, et parcourt la même arborescence de montage. L'erreur inverse coûte autant : un espace de noms de simple rangement, pris pour une frontière, ne bloque rien sans contrôle d'accès ni quotas associés. Les droits accordés au niveau global s'y appliquent sans restriction, et le cloisonnement supposé n'existe que sur le papier.
Explication de la marmotte
Imagine deux classes dans ton lycée, chacune avec une élève appelée Léa. Quand le prof de la seconde B appelle « Léa », personne en seconde C ne se lève : le prénom ne compte qu'à l'intérieur de sa classe. Un ordinateur fait pareil avec les noms qu'il manipule. On crée des cases séparées, et un même nom peut exister dans chaque case sans provoquer de confusion. Parfois ces cases servent juste à ranger, comme des classeurs avec une étiquette. Parfois elles enferment vraiment un programme, qui croit alors être seul sur la machine et ne voit pas ses voisins.
Où ce terme est utilisé
- Docker ou Podman en auto-hébergement : root, rootless, isolation (7 occurrences)
- Mettre en place la fédération d’identité de charge (6 occurrences)
- Jeton de compte de service Kubernetes monté par défaut (5 occurrences)
- Isolation réseau multi-tenant avec VPC et NetworkPolicy (4 occurrences)
- Laisser une équipe se tromper sans casser la production (3 occurrences)
- Séparer plan de contrôle et plan de données (3 occurrences)
- EBPF pour observer et bloquer dans le noyau Linux (2 occurrences)
- Exploiter une race condition TOCTOU sur fichier privilégié (2 occurrences)
- Isolation des conteneurs Docker : namespaces, cgroups et évasions (2 occurrences)
- Pourquoi le moindre privilège échoue en production (2 occurrences)