Sécurité des conteneurs et des images Docker de bout en bout

Les conteneurs promettent une unité logicielle propre et reproductible, mais cette promesse ne tient que si l'image, le pipeline de construction, le registre et l'exécution sont sécurisés ensemble. Une vulnérabilité introduite dans une image de base, un secret cuit dans une couche ou une étape de construction compromise peut voyager sans changement vers chaque environnement qui tire l'artefact. Cet article parcourt le cycle de vie du conteneur de bout en bout du point de vue du défenseur, dans le cadre comprendre pour défendre. Nous regardons où le risque entre à chaque étape, quelle télémétrie permet de repérer l'abus et quels contrôles rendent une image de conteneur digne de confiance, du portable du développeur au nœud de production.

La chaîne d'approvisionnement des conteneurs comme surface d'attaque

Il aide de penser une image de conteneur non comme un fichier mais comme une chaîne de possession. Le code source devient une construction, la construction tire des dépendances et une image de base, le résultat est poussé vers un registre, et un ordonnanceur finit par l'exécuter quelque part. Chaque maillon est un endroit où un attaquant ou un accident peut injecter quelque chose d'imprévu. L'objectif défensif est la provenance : en tout point, vous devriez pouvoir répondre d'où vient une image, ce qui la compose, qui l'a construite et si elle a été altérée depuis. Quand la provenance manque, une seule couche empoisonnée peut se propager en silence à travers toute votre flotte.

C'est pourquoi la pensée de chaîne d'approvisionnement se trouve aujourd'hui au centre de la sécurité des conteneurs. Il ne suffit pas d'analyser l'image finale ; il faut sécuriser le processus qui la produit et pouvoir prouver que ce qui tourne en production est exactement ce que votre pipeline a construit.

Choisir et maintenir les images de base

La majeure partie de la surface d'attaque d'une image vient de ce dont vous avez hérité, non de ce que vous avez écrit. Une image de base pleine de shells, de gestionnaires de paquets et d'utilitaires système donne à un intrus une boîte à outils au moment où il atterrit. Préférez des bases minimales ou distroless ne contenant que votre application et ses dépendances d'exécution, et épinglez-les à un digest immuable plutôt qu'à une étiquette mutable comme latest, afin qu'une reconstruction ne tire pas en silence une image différente, peut-être trafiquée. Reconstruisez régulièrement pour absorber les correctifs de sécurité en amont ; un digest épinglé qui ne se met jamais à jour est sûr face à la surprise mais accumule lentement des vulnérabilités connues.

Suivez la provenance de vos images de base. Favorisez des éditeurs officiels ou vérifiés et traitez une source non maintenue comme un passif. Moins une image contient de paquets, plus petite est la surface à corriger et plus silencieux votre analyseur de vulnérabilités, ce qui rend à son tour les vrais résultats plus visibles.

Construire des images en toute sécurité

La construction est l'endroit où les secrets fuient le plus souvent. Un identifiant passé comme argument de construction ou copié à une étape puis effacé à une étape ultérieure vit encore dans l'historique de l'image, récupérable par quiconque la tire. Utilisez des montages de secret au moment de la construction qui ne persistent jamais dans une couche, et gardez les secrets entièrement hors du Dockerfile. Les constructions multi-étapes permettent de compiler ou d'installer dans une étape de construction épaisse et de ne copier que l'artefact fini dans une étape finale allégée, laissant derrière compilateurs, caches de paquets et identifiants intermédiaires.

Exécutez le conteneur en tant qu'utilisateur non root en déclarant un utilisateur dédié dans l'image, afin que même une exécution qui ne remplace pas l'utilisateur ne tourne toujours pas en root. Choisissez une disposition de système de fichiers compatible lecture seule, évitez ADD avec des URL distantes et préférez COPY avec des sources explicites. Générez une nomenclature logicielle pendant la construction pour disposer d'un inventaire de chaque composant, inestimable le jour où une nouvelle vulnérabilité est divulguée et où vous devez savoir instantanément si vous êtes touché.

Signer et vérifier la provenance

Une signature transforme la provenance d'une affirmation en quelque chose que vous pouvez imposer. Signez les images à la fin de la construction avec un outil comme cosign de Sigstore et enregistrez des attestations décrivant comment l'image a été construite et ce qui la compose. Au déploiement, un contrôleur d'admission ou un moteur de politiques vérifie cette signature et refuse d'exécuter tout ce qui n'est pas signé ou signé par une clé inattendue. Cela ferme l'écart entre le registre et l'exécution : même si un attaquant pousse une image malveillante vers votre registre, elle ne peut tourner sans une signature valide de votre pipeline.

La signature sans clé liée à votre identité CI supprime la charge de gérer des clés de signature à longue durée de vie et lie chaque signature à un flux de travail vérifiable. La propriété défensive clé est que la confiance découle de votre système de construction, non du simple fait qu'une image réside dans votre registre.

Analyser et verrouiller

L'analyse de vulnérabilités a sa place en plusieurs points : dans la demande de fusion pour que les développeurs voient les problèmes tôt, dans le pipeline comme une porte qui peut faire échouer la construction, et en continu contre les images déjà dans le registre, car de nouvelles vulnérabilités sont divulguées contre des images inchangées. Configurez la porte avec une politique adaptée à votre risque — par exemple bloquer sur les problèmes critiques et élevés corrigeables tout en suivant le reste — et donnez aux équipes un chemin d'exception clair avec expiration, pour que les portes ne soient pas simplement désactivées sous la pression des délais. Analysez aussi les secrets intégrés et les mauvaises configurations, pas seulement les vulnérabilités de paquets connues.

Souvenez-vous qu'un analyseur signale ce qu'il sait aujourd'hui. Associez-le à la nomenclature logicielle afin que, lorsqu'une vulnérabilité toute nouvelle survient, vous puissiez interroger votre inventaire plutôt que de réanalyser le monde. La combinaison d'une porte et d'un inventaire est ce qui vous permet de réagir en minutes plutôt qu'en jours.

Protection à l'exécution et hygiène du registre

Une fois qu'un conteneur tourne, les contrôles se déplacent vers sa contrainte et son observation. Abandonnez les capacités Linux, appliquez un profil seccomp, exécutez avec un système de fichiers racine en lecture seule et n'accordez jamais le drapeau privileged ni ne montez le socket Docker de l'hôte dans un conteneur, car l'un ou l'autre remet effectivement le nœud. Côté registre, exigez l'authentification, restreignez étroitement les droits de tirage et de poussée, activez des étiquettes immuables pour qu'une image publiée ne soit pas échangée sous les consommateurs, et élaguez les images non fiables ou périmées. Un registre où n'importe qui peut pousser est un canal de distribution pour tout ce qu'un attaquant veut exécuter.

Isolez les exécuteurs de construction des identifiants de production. Un exécuteur CI compromis avec un accès large est l'un des points d'appui les plus dommageables qu'un attaquant puisse obtenir, car il peut réécrire les images mêmes auxquelles vous faites confiance. Donnez aux exécuteurs le moindre privilège, des identités éphémères et aucun accès permanent à la production.

Détection : signaux au long du cycle de vie

La détection couvre toute la chaîne. Dans le pipeline, surveillez les constructions qui tirent de sources inattendues, les échecs de vérification de signature et les pics soudains de résultats d'analyse. Dans le registre, alertez sur les poussées depuis des identités inhabituelles, les tirages d'images jamais promues et les mutations d'étiquette là où vous attendiez l'immuabilité. À l'exécution, un capteur comportemental comme Falco ou un EDR conscient des conteneurs signale un shell ouvert dans un conteneur, un processus écrivant sur un chemin en lecture seule, une connexion sortante inattendue ou une tentative d'atteindre le socket du runtime de conteneurs. Corréler une poussée de registre avec un comportement d'exécution anormal révèle souvent une image empoisonnée avant qu'elle ne se propage.

Conservez ces journaux plus longtemps que le temps de présence typique d'un attaquant et expédiez-les hors des hôtes qui les génèrent. Les données de provenance, les résultats de vérification de signature et les alertes d'exécution ensemble vous permettent de répondre à la question de tout incident : qu'est-ce qui a tourné, d'où cela venait-il, et cela tourne-t-il encore ailleurs ?

Une liste de contrôle pratique

Base : minimale ou distroless, épinglée à un digest, d'un éditeur vérifié, reconstruite régulièrement. Construction : utilisateur non root, multi-étapes, montages de secret plutôt qu'arguments, nomenclature logicielle générée, pas de socket hôte. Provenance : images signées, attestations enregistrées, l'admission vérifie les signatures. Analyse : dans la fusion, dans le pipeline comme porte, en continu dans le registre, analyse de secrets et de mauvaises configurations incluse, exceptions à durée limitée. Registre : authentifié, poussée au moindre privilège, étiquettes immuables, images périmées élaguées. Exécution : capacités abandonnées, seccomp, système de fichiers en lecture seule, pas de privileged, pas de montage du socket Docker. Détection : alertes de pipeline, de registre et d'exécution corrélées, journaux conservés au-delà du temps de présence.

FAQ : L'analyse rend-elle mes images sûres ?

L'analyse est nécessaire mais pas suffisante. Elle vous informe des vulnérabilités connues dans des composants connus, ce qui est précieux, mais ne dit rien d'une étape de construction malveillante, d'un secret fuité qu'elle ne reconnaît pas, d'une exécution surprivilégiée ou d'une vulnérabilité toute nouvelle divulguée demain. Traitez l'analyse comme une couche parmi provenance, signature, images minimales, confinement à l'exécution et détection. La sécurité vient de la combinaison, non d'une seule porte.

FAQ : Les images distroless ou minimales sont-elles toujours meilleures ?

Elles réduisent radicalement la surface d'attaque et le bruit de l'analyseur, et pour la plupart des services de production elles sont le bon choix par défaut. Le compromis est la débogabilité, puisqu'il n'y a ni shell ni gestionnaire de paquets pour fouiller quand quelque chose casse. La réponse mûre est de garder les images de production minimales et d'utiliser des conteneurs de débogage éphémères ou une image séparée plus riche pour le diagnostic, afin d'avoir une petite surface en production sans perdre la capacité d'enquêter.

Conclusion

La sécurité des conteneurs n'est pas un contrôle unique mais une chaîne qui n'est aussi forte que son maillon le plus faible. Partez d'une base minimale, épinglée et vérifiée ; construisez sans fuite de secrets et en tant qu'utilisateur non root ; signez et attestez pour que la provenance soit imposable ; analysez et verrouillez à chaque étape ; verrouillez le registre et l'exécution ; et instrumentez tout le cycle de vie pour que l'abus soit visible. Quand la provenance coule sans rupture de la source au conteneur en cours d'exécution, une couche empoisonnée n'a nulle part où se cacher, et la reproductibilité qui rend les conteneurs attrayants les rend aussi défendables.