Des applications conteneurisées rendent-elles la machine hôte inviolable ?

Avec Docker et Kubernetes, la conteneurisation est devenue la norme. Elle permet de déployer plus vite, plus proprement, et de mieux organiser ses applications.

En conséquence, une idée revient très souvent :

Mes applications sont dans des conteneurs, donc même si l’une d’elle se fait compromettre, l’hôte est protégé.

En pratique, ce raisonnement est dangereux.

La conteneurisation ne protège pas automatiquement la machine hôte, et dans certains cas, elle peut même donner un faux sentiment de sécurité.

Conteneurs VS machines virtuelles

Quand on parle de virtualisation, on pense aux conteneurs et aux machines virtuelles. Mais leur fonctionnement est très différent.

Une machine virtuelle repose sur un hyperviseur qui isole fortement le système invité du système hôte. Chaque VM a son propre kernel, et même si le matériel n’est pas dédié, la barrière est solide. Accéder à l’hôte depuis une VM compromise n’est pas chose aisée et nécessite par exemple l’exploitation d’une faille dans l’hyperviseur.

Un conteneur, lui, fonctionne autrement.
Il partage le kernel de la machine hôte et s’appuie sur des mécanismes d’isolation logiciels comme les namespaces et les cgroups. Cette isolation est suffisante pour séparer des applications entre elles, mais elle n’a pas le même niveau de robustesse qu’une VM.

Autrement dit : un conteneur isole, mais il ne cloisonne pas complètement.

Ecosystème virtuel, mais surface d’attaque bien réelle

Dans un environnement conteneurisé, plusieurs choses peuvent être exploitées directement ou en conjonction avec d’autres vulnérabilités par un attaquant aguéri, notamment :

• images Docker obsolètes ou vulnérables
• secrets stockés en clair dans des variables d’environnement
• conteneurs lancés en root “par commodité”
• permissions trop vastes accordées aux conteneurs
• composants Docker ou Kubernetes exposés inutilement

Il n’est pas rare de voir des environnements où une compromission applicative depuis l’extérieur peut ouvrir la porte à des accès bien plus sensibles.

L’évasion de conteneur

Contrairement à ce que l’on pourrait penser, sortir d’un conteneur n’est pas forcément un scénario complexe et anecdotique.

Un exemple courant est l’accès au socket Docker (/var/run/docker.sock).
Un conteneur qui y a accès peut piloter le daemon Docker, lancer d’autres conteneurs et monter le système de fichiers de l’hôte. Le résultat équivaut à un accès root sur la machine.

Autre cas fréquent : les conteneurs lancés avec des capabilities Linux trop permissives. Certaines capabilities Linux affaiblissent fortement l’isolation du conteneur et facilitent l’évasion vers l’hôte, notamment en rendant exploitables des vulnérabilités du kernel.

Dernier exemple : le kernel étant partagé, une vulnérabilité locale exploitable peut également permettre à un attaquant de compromettre l’hôte.

Kubernetes n’est pas la silver bullet

Kubernetes est un excellent outil d’orchestration, mais ce n’est pas une garantie de sécurité par défaut.

Un cluster mal configuré peut permettre :

• l’accès non autorisé à l’API
• la récupération de secrets
• des escalades de privilèges via des rôles trop permissifs
• des mouvements latéraux entre pods, puis vers les nœuds

Autrement dit :

Compromettre une seule application exposée peut parfois suffire à accéder aux données d’autres applications, générer des interruptions de service ou même compromettre tout le cluster.

Ce que la conteneurisation permet réellement

La conteneurisation apporte de vrais bénéfices :

• une meilleure organisation / gestion des applications
• une résilience supérieure grâce à la réplication
• une portabilité accrue
• une certaine limitation des impacts en cas de compromission (niveau d’abstraction et complexité supplémentaires pour un attaquant)

Mais elle ne remplace pas une vraie stratégie de sécurité pensée dès la conception. Sans mise en place des bonnes pratiques en la matière, sans contrôles d’accès stricts et sans tests d’intrusion réguliers, l’hôte peut rester vulnérable.

Conclusion

Placer ses applications en conteneurs sous la supervision d’un orchestrateur est une bonne pratique technique, mais attention à ne pas confondre cette séparation logique avec une véritable isolation.

La question à se poser :

Que peut faire un attaquant s’il compromet un conteneur aujourd’hui ? Lire des secrets ? Pivoter vers d’autres pods ? Accéder à l’hôte ?

C’est précisément ce que permet de mesurer un pentest.