Conteneurs et sécurité : isolation et images

Les conteneurs ont changé la manière de déployer des applications : on empaquette un programme avec tout ce dont il a besoin, et on le fait tourner n'importe où de la même manière. Pratique, rapide, léger. Mais cette légèreté a un prix : l'isolation d'un conteneur n'est pas celle d'une machine virtuelle. Cette leçon explique ce qu'un conteneur protège, ce qu'il ne protège pas, et comment réduire les risques dans les images et à l'exécution.

Conteneur ou machine virtuelle ?

Une analogie immobilière aide à comprendre. Une machine virtuelle est une maison individuelle : elle a ses propres murs, son propre système, séparée des voisines. Un conteneur est un appartement dans un immeuble : il a sa porte, ses pièces et son compteur, mais tous les appartements partagent la structure de l'immeuble, c'est-à-dire le noyau du système d'exploitation de l'hôte.

Techniquement, l'isolation d'un conteneur repose sur deux mécanismes du noyau Linux :

• les espaces de noms (namespaces), qui donnent à chaque conteneur sa propre vue des processus, du réseau, du système de fichiers ;
• les groupes de contrôle (cgroups), qui limitent les ressources consommées (processeur, mémoire).

La conséquence est directe : une faille dans le noyau peut permettre une « évasion » du conteneur, ce qui est plus difficile avec une machine virtuelle. Les conteneurs sont donc sûrs si l'on s'en occupe, pas par magie.

Les trois zones de risque

1. L'image

Une image est le modèle à partir duquel on lance des conteneurs : un système minimal, des bibliothèques, l'application. Elle est construite à partir d'une image de base, souvent récupérée sur un registre public. Risques :

• Vulnérabilités connues dans la base ou les dépendances : une image figée il y a un an embarque les failles d'il y a un an.
• Images de provenance douteuse : télécharger une image inconnue, c'est exécuter le code de quelqu'un d'autre.
• Secrets embarqués : un mot de passe ou une clé écrits dans l'image restent lisibles par quiconque obtient l'image, y compris dans les couches historiques.
• Image trop riche : outils inutiles (compilateurs, interpréteurs de commandes complets) qui augmentent la surface d'attaque.

2. L'exécution

La configuration du conteneur au lancement compte autant que l'image :

• Conteneur privilégié : il reçoit presque tous les droits de l'hôte, ce qui supprime l'essentiel de l'isolation.
• Exécution en superutilisateur : le processus dans le conteneur est « root » ; en cas de compromission, l'attaquant dispose de droits étendus.
• Montage de ressources sensibles de l'hôte : partager avec le conteneur un dossier système, ou la socket du moteur de conteneurs, équivaut à lui donner les clés de l'hôte.
• Droits (capabilities) excessifs et système de fichiers modifiable alors qu'il pourrait être en lecture seule.

3. L'orchestration

Lorsque des centaines de conteneurs tournent ensemble, un orchestrateur les gère. Ses propres erreurs de configuration sont un risque majeur : interface d'administration exposée, droits d'accès trop larges (le contrôle des accès fondé sur les rôles, ou RBAC, doit être strict), secrets stockés en clair, réseau interne où tous les conteneurs peuvent se parler librement.

Un exemple à analyser : deux versions de description d'image

Voici deux descriptions de construction d'image pour une petite application web. Ce sont des exemples génériques, destinés à la relecture dans votre laboratoire.

# Version à risque
FROM base-complete:latest
COPY . /app
ENV MOT_DE_PASSE_BASE=exemple-a-ne-jamais-faire
RUN installer-tous-les-outils
EXPOSE 22 80 3306
CMD ["/app/demarrer"]

Qu'est-ce qui pose problème ? L'étiquette latest change dans le temps : on ne sait pas ce que l'on exécute. Tout le répertoire est copié, y compris peut-être des fichiers de configuration et des secrets. Un mot de passe est écrit dans l'image. On installe plus d'outils que nécessaire. On expose des ports qui n'ont rien à faire là (accès à distance, base de données). Et rien n'empêche l'exécution en superutilisateur.

# Version améliorée
FROM base-minimale:version-fixee
WORKDIR /app
COPY --chown=appuser:appuser application/ /app/
RUN creer-utilisateur-sans-privileges appuser
USER appuser
EXPOSE 8080
CMD ["/app/demarrer"]

Ici : une image de base minimale et à version figée (idéalement vérifiée par son empreinte), uniquement les fichiers nécessaires, un utilisateur sans privilèges, un seul port exposé, aucun secret dans l'image (les secrets arrivent à l'exécution, via un mécanisme dédié). Les noms de commandes sont volontairement génériques : l'important est le raisonnement.

Les bonnes pratiques en pratique

• Choisir des images de base minimales et de confiance, provenant de sources vérifiées.
• Analyser les images à la recherche de vulnérabilités connues, régulièrement et automatiquement (dans la chaîne de construction), et reconstruire lorsque des correctifs sont publiés. Les bases de vulnérabilités publiques (cve.org et nvd.nist.gov) alimentent ces analyses.
• Ne pas exécuter en superutilisateur, retirer les droits inutiles, utiliser un système de fichiers en lecture seule lorsque c'est possible.
• Interdire les conteneurs privilégiés sauf exception justifiée et documentée.
• Gérer les secrets séparément : un coffre-fort ou le mécanisme de secrets de l'orchestrateur, jamais dans l'image ni dans le dépôt.
• Cloisonner le réseau : par défaut, un conteneur ne doit parler qu'à ceux dont il a besoin.
• Limiter les ressources pour éviter qu'un conteneur ne prive les autres de mémoire ou de processeur.
• Journaliser et superviser les conteneurs, y compris leur cycle de vie (création, arrêt, commandes lancées).
• Mettre à jour l'hôte : le noyau partagé doit être corrigé régulièrement.

Des guides de référence existent : l'OWASP (owasp.org) publie des aide-mémoire de sécurité sur les conteneurs et sur l'orchestration, et le NIST (nist.gov) a publié un guide d'ensemble sur la sécurité des conteneurs.

Penser « éphémère »

Les conteneurs sont conçus pour être remplacés plutôt que réparés : si une image est corrigée, on la redéploie. Cette philosophie est un atout de sécurité : on ne se connecte pas à un conteneur pour le « soigner » à la main ; on corrige l'image et on redéploie. Elle facilite aussi la réponse à incident : on peut isoler et remplacer un conteneur suspect en quelques secondes, à condition d'avoir conservé les journaux et les preuves avant de le détruire (voir la leçon sur la réponse à incident).

À vous de jouer

Voici la liste des constats relevés sur le déploiement fictif d'Atelier Boréal. Pour chacun, indiquez s'il s'agit d'un risque d'image, d'exécution ou d'orchestration, et la correction :

1. Le conteneur du site tourne en mode privilégié « parce qu'il ne démarrait pas autrement ».
2. L'image utilisée n'a pas été reconstruite depuis plus d'un an.
3. L'interface d'administration de l'orchestrateur est accessible depuis Internet, avec un mot de passe par défaut.
4. Une clé d'accès à la base de données est écrite dans l'image.