Sécuriser un conteneur Docker

L’adoption de la conteneurisation a profondément transformé les pratiques de développement et de déploiement des applications. Des solutions comme Docker permettent aujourd’hui d’exécuter des applications dans des environnements isolés, reproductibles et facilement déployables.

Cependant, cette flexibilité s’accompagne de nouveaux enjeux de sécurité. Des images vulnérables, des privilèges excessifs ou une mauvaise gestion des secrets peuvent rapidement devenir des vecteurs d’attaque. Dans de nombreux cas, les incidents observés résultent davantage de configurations permissives que de failles techniques complexes.

Ornisec vous propose ici quelques bonnes pratiques pour renforcer la sécurité de vos images et de vos conteneurs Docker.

Utiliser des images de base fiables et maîtrisées

La sécurité d’un conteneur commence par l’image sur laquelle il repose. Une image compromise ou contenant des dépendances vulnérables introduit un risque immédiat dans toute la chaîne de déploiement. Il est donc recommandé d’utiliser des images officielles ou maintenues activement, notamment celles disponibles sur Docker Hub.

Dans un contexte professionnel, il est toutefois préférable de mettre en place un registre interne afin de contrôler les images utilisées dans l’infrastructure. Des solutions comme Harbor ou GitHub Container Registry permettent de centraliser les images et d’intégrer des mécanismes de scan de vulnérabilités.

Cette approche limite également un scénario fréquent : l’exploitation par un attaquant d’une dépendance obsolète présente dans une image publique. L’utilisation d’images minimalistes, par exemple basées sur Alpine ou distroless, permet de réduire la surface d’attaque en limitant les composants inutiles.

Appliquer le principe du moindre privilège

Dans de nombreux environnements, les conteneurs sont exécutés avec des privilèges trop élevés. Certaines images fonctionnent encore avec l’utilisateur root, ce qui peut offrir des capacités importantes à un attaquant en cas de compromission de l’application.

Le principe du moindre privilège consiste à limiter les droits accordés à l’application au strict nécessaire. Concrètement, cela implique de créer un utilisateur dédié dans l’image et d’exécuter l’application avec cet utilisateur.

Dockerfile non sécurisé :

Dans cet exemple, l’application s’exécute avec les privilèges root.

Dockerfile amélioré :

Cette configuration réduit l’impact potentiel d’une compromission. Elle peut être complétée par la limitation des capacités Linux et bien d’autres techniques.

Certaines organisations choisissent également d’utiliser Podman. Contrairement à Docker, Podman fonctionne sans démon central et peut être utilisé en mode rootless, ce qui réduit les risques liés à un processus privilégié sur l’hôte.

Sécuriser le moteur de conteneurisation

Le moteur de Docker constitue un composant critique. Un accès au socket /var/run/docker.sock permet potentiellement de contrôler les conteneurs et d’interagir avec le système hôte.

Dans plusieurs scénarios d’attaque, un accès à ce socket permet par exemple de lancer un conteneur privilégié ou de monter le système de fichiers de l’hôte. Il est donc essentiel de restreindre strictement cet accès, de limiter les utilisateurs du groupe docker et de ne jamais exposer l’API Docker sur un port non sécurisé.

Renforcer l’isolation des conteneurs

La sécurité des conteneurs dépend également de leur niveau d’isolation. Une segmentation réseau insuffisante peut permettre à un attaquant ayant compromis un service de se déplacer latéralement vers d’autres conteneurs.

La mise en place de réseaux dédiés et la séparation des environnements (développement, test, production) permettent de limiter ces risques. Les mécanismes de sécurité du noyau Linux, comme AppArmor ou SELinux, renforcent également cette isolation en contrôlant les actions autorisées pour chaque conteneur.

Gérer les secrets de manière sécurisée

La gestion des secrets constitue une erreur fréquente dans les environnements conteneurisés. Il n’est pas rare de trouver des mots de passe ou des clés API directement intégrés dans les images.

Par exemple :

ENV DB_PASSWORD=mysecretpassword

Dans ce cas, un attaquant ayant accès à l’image ou aux métadonnées du conteneur peut récupérer ces informations et accéder à d’autres services.

Une approche plus sûre consiste à externaliser les secrets et à les injecter au moment de l’exécution via des solutions comme HashiCorp Vault, Docker Secrets ou AWS Secrets Manager.

Superviser et automatiser les contrôles de sécurité

Enfin, la sécurité d’un environnement conteneurisé doit s’appuyer sur une supervision continue. Des plateformes comme Prometheus et Grafana permettent de suivre l’activité des conteneurs, tandis que des outils comme Falco peuvent détecter des comportements anormaux à l’exécution.

La centralisation des journaux dans un SIEM tel que Elastic Stack ou Splunk améliore également la détection d’incidents.

Ces contrôles doivent idéalement être intégrés dans les pipelines CI/CD. Des plateformes comme Jenkins ou GitHub Actions permettent par exemple d’automatiser la reconstruction des images et l’analyse de vulnérabilités via des outils comme Trivy ou Clair.

Pour conlure

Une image de conteneur reste une application qui doit être protégée au même titre que n’importe quel composant du système d’information. Sa sécurisation repose sur un ensemble cohérent de pratiques couvrant la construction des images, leur configuration et leur supervision.

Ornisec accompagne les organisations dans l’audit et la sécurisation de leurs environnements conteneurisés, afin d’identifier les mauvaises pratiques exploitables par un attaquant et de mettre en place des architectures et politiques adaptées à leur contexte.

Pour aller plus loin

• Docker Security Documentation
• Application Container Security Guide (NIST SP 800-190)
• OWASP Docker Security Cheat Sheet