Conteneur
Infrastructure
Processus isolé qui embarque une application avec ses dépendances et partage le noyau du système hôte. Plus léger qu'une machine virtuelle, il démarre en quelques secondes et se relance à l'identique sur tout hôte au noyau compatible.
Isolation par le noyau : Les namespaces donnent au processus sa propre vue des processus, du réseau et du système de fichiers, et les cgroups plafonnent sa consommation de CPU et de mémoire. Aucun système d'exploitation invité : tous les conteneurs d'une machine utilisent le même noyau.
Image et instance : L'image est un modèle figé, découpé en couches en lecture seule. Le conteneur en est une instance en cours d'exécution, avec une couche inscriptible éphémère : ce qu'on y écrit disparaît avec lui, sauf si on monte un volume.
Portabilité : L'image fige l'application et ses bibliothèques, ce qui rend le déploiement reproductible d'un poste à la production. Le conteneur a fait disparaître le « ça marche sur ma machine » pour le remplacer par « ça marche dans mon image », ce qui reste un progrès, mais un progrès modeste.
Frontière de sécurité : Partager le noyau signifie qu'une faille du noyau peut traverser la cloison. Un conteneur lancé en root ou en mode privilégié n'isole presque plus rien. Un conteneur confine du code de confiance, il ne sépare pas des locataires hostiles : quand l'isolation doit être forte, on ajoute une machine virtuelle ou un moteur d'exécution qui n'expose pas le noyau de l'hôte (gVisor, Kata Containers).
Ce qui arrive si on s'en passe
Sans conteneur, l'application s'exécute directement sur l'hôte, au milieu des autres processus. Une faille exploitée dans ce service donne alors accès à tout ce que son compte peut atteindre sur la machine : fichiers des autres applications, secrets stockés localement, processus voisins visibles et, sous le même utilisateur, manipulables. Les dépendances sont installées au niveau du système : une mise à jour destinée à une application peut en casser une autre, et une bibliothèque vulnérable reste partagée par tous les services qui l'utilisent. L'environnement n'est plus reproductible ; ce qui a été testé ne correspond pas forcément à ce qui tourne en production, et reconstruire un service à l'identique après un incident devient plus lent et moins fiable. À garder en tête : le conteneur réduit l'exposition sans constituer une frontière absolue, puisque le noyau de l'hôte reste partagé.
Explication de la marmotte
Sur un cargo, on range les marchandises dans de grandes boîtes métalliques qui ont toutes la même taille. Peu importe ce qu'il y a dedans : la grue, le camion et le bateau savent les manipuler. Pour un programme, c'est pareil. On le range dans une boîte avec tout ce dont il a besoin pour fonctionner, comme ses outils et ses réglages. Ensuite, on peut lancer cette boîte sur n'importe quel ordinateur, et le programme marche de la même façon. Plusieurs boîtes peuvent tourner sur le même ordinateur sans se mélanger. Chacune croit être seule, alors qu'elles partagent toutes le même moteur en dessous.
Où ce terme est utilisé
- Isolation des conteneurs Docker : namespaces, cgroups et évasions (44 occurrences)
- Docker ou Podman en auto-hébergement : root, rootless, isolation (33 occurrences)
- Auditer l'héritage des permissions et le droit effectif (16 occurrences)
- Cairn, un moteur multi-agents de recherche dans un espace d'états (16 occurrences)
- Strix, des agents de test d'intrusion autonomes en bac à sable (14 occurrences)
- Pollution de variable d'environnement héritée dans un conteneur (12 occurrences)
- Écrire un Dockerfile durci avec condensé, multi-étapes et non root (10 occurrences)
- Conteneurs, Kubernetes, CNI et service mesh (9 occurrences)
- Hermes Agent, le harnais d'agent autonome de Nous Research (9 occurrences)
- L'entropie au démarrage (9 occurrences)