Sécurité des conteneurs : ce qui change par rapport à un serveur classique

Les conteneurs ont été adoptés pour des raisons d’exploitation, pas de sécurité. Ils déplacent pourtant plusieurs hypothèses sur lesquelles reposaient les pratiques établies — et les équipes sécurité arrivent souvent sur le sujet après que les choix d’architecture ont été faits.

L’objet de cet article n’est pas de dresser une liste de durcissement, mais d’identifier ce qui change réellement dans le raisonnement.

Un conteneur n’est pas une machine virtuelle

C’est la confusion fondatrice. Une machine virtuelle possède son propre noyau ; l’isolation repose sur l’hyperviseur. Un conteneur partage le noyau de l’hôte ; l’isolation repose sur des mécanismes du système — espaces de noms, groupes de contrôle, capacités, filtrage d’appels système.

Conséquence pratique : une vulnérabilité du noyau de l’hôte est exploitable depuis un conteneur. La surface d’attaque commune est bien plus large qu’avec la virtualisation classique, et les cloisonnements qu’on croyait acquis ne le sont plus au même degré.

Cela ne condamne pas le modèle. Cela signifie qu’un conteneur ne doit pas être traité comme une frontière de confiance suffisante entre deux environnements de sensibilité différente. Faire cohabiter de la production et de la recette sur le même hôte parce que « ce sont des conteneurs séparés » est un raccourci que l’analyse de risque ne soutient pas.

Le privilège par défaut

Beaucoup d’images officielles exécutent leur processus principal en tant que superutilisateur, parce que c’est ce qui demande le moins de configuration. Combiné à un montage du descripteur du moteur de conteneurisation — pratique courante dans les chaînes d’intégration — cela équivaut à donner l’administration de l’hôte au processus contenu.

Les corrections sont connues et peu coûteuses : exécution sous un compte non privilégié, système de fichiers en lecture seule quand l’application le permet, retrait des capacités inutiles, refus des conteneurs en mode privilégié. Elles se posent au niveau de la plateforme, sous forme de règles d’admission, plutôt qu’au niveau de chaque équipe applicative — sinon elles ne seront appliquées que par celles qui y pensent.

L’image est une dépendance qu’on oublie de suivre

Une image est construite à partir d’une image de base, qui contient une distribution complète, qui contient des bibliothèques. Une application dont le code est irréprochable peut embarquer des dizaines de composants vulnérables sans que personne ne l’ait décidé.

Deux différences majeures avec un serveur classique :

• Il n’y a pas de mise à jour en place. Un conteneur ne se corrige pas, il se remplace. Une image construite il y a huit mois et jamais reconstruite contient huit mois de vulnérabilités non corrigées, même si l’application tourne parfaitement.
• Les étiquettes mentent. Une image référencée par une étiquette mobile peut changer de contenu sans changer de nom. Deux déploiements identiques sur le papier peuvent exécuter des binaires différents. Le référencement par empreinte cryptographique est la seule façon de savoir ce qui tourne.

La conséquence organisationnelle est plus lourde que la conséquence technique : elle impose une reconstruction périodique des images, donc un pipeline capable de rejouer un déploiement sans intervention humaine. Les équipes qui n’ont pas cette capacité ne pourront pas corriger dans un délai raisonnable, quel que soit l’outil de détection installé.

Les secrets

Le réflexe naturel — passer les secrets par variables d’environnement — est le plus mauvais. Une variable d’environnement est lisible dans la description de l’objet déployé, dans les journaux d’erreur qui recopient l’environnement, et par tout processus du conteneur. Elle se retrouve dans les exports de configuration et dans les dépôts de code lorsqu’elle est écrite dans un fichier de déploiement.

Les mécanismes de gestion de secrets natifs des orchestrateurs ne chiffrent pas nécessairement au repos sans configuration explicite : c’est un point à vérifier, pas à supposer.

Le réseau devient horizontal

Par défaut, dans la plupart des orchestrateurs, tout conteneur peut joindre tout autre conteneur. Le cloisonnement réseau qui existait entre serveurs disparaît au moment de la migration, sans que personne ne l’ait décidé — c’est un effet de bord de l’adoption, pas un choix.

Rétablir un cloisonnement suppose de déclarer explicitement les flux autorisés. C’est faisable, mais cela demande de connaître les flux réels de l’application — information qui manque souvent, et que la migration aurait été le bon moment pour établir.

La détection dans un environnement éphémère

Un conteneur peut vivre quelques minutes. Les journaux stockés dans son système de fichiers disparaissent avec lui. Une analyse post-incident sur une charge redémarrée trois fois depuis les faits ne dispose de rien si la journalisation n’a pas été externalisée dès la conception.

C’est un point qui se traite en amont ou pas du tout : personne ne reconstitue a posteriori des traces qui n’ont pas été collectées.

Ce qu’il faut retenir

Les conteneurs ne sont ni plus ni moins sûrs que ce qu’ils remplacent. Ils déplacent la sécurité vers l’amont : dans la construction des images, dans les règles de la plateforme, dans la configuration du déploiement. Une organisation dont les contrôles reposent sur l’intervention manuelle en production perd l’essentiel de ses moyens d’action en migrant — non par régression technique, mais parce que le point où s’exerçait le contrôle a disparu.

Sources

• NIST — SP 800-190, Application Container Security Guide
• ANSSI — recommandations de sécurité relatives au déploiement de conteneurs
• CIS — Benchmarks pour les moteurs de conteneurisation et les orchestrateurs