Sécurisation de Docker : risques, avantages et checklist

Docker a rendu le déploiement d'applications simple et reproductible, mais un conteneur n'est pas une machine virtuelle : il partage le noyau de l'hôte. La sécurisation de Docker repose donc sur un équilibre entre les protections que la technologie apporte nativement et les erreurs de configuration qui les annulent. Cet article présente les avantages en cybersécurité, les principaux risques, puis une checklist de durcissement fondée sur des référentiels reconnus.

À retenir : Docker réduit certains risques et en crée d'autres. Un conteneur mal configuré (privilèges excessifs, socket exposé, image non contrôlée) peut donner à un attaquant un accès complet à l'hôte.

Les avantages de Docker pour la sécurité

D'après la documentation officielle de Docker, l'isolation repose sur des mécanismes éprouvés du noyau Linux :

• Les espaces de noms (namespaces) empêchent les processus d'un conteneur de voir ou d'affecter ceux des autres conteneurs ou de l'hôte. Chaque conteneur dispose aussi de sa propre pile réseau.
• Les groupes de contrôle (cgroups) limitent la mémoire, le processeur et les entrées-sorties disque par conteneur, ce qui évite qu'un seul conteneur ne monopolise les ressources et provoque un déni de service.
• Les capacités Linux sont réduites par défaut : Docker retire toutes les capacités sauf celles nécessaires, ce qui empêche même un processus root du conteneur de monter des systèmes de fichiers, d'ouvrir des sockets bruts ou de charger des modules noyau.
• Des couches de protection supplémentaires sont prises en charge : seccomp, AppArmor, SELinux, ainsi que les espaces de noms utilisateur, qui associent le root du conteneur à un utilisateur non privilégié de l'hôte.

À ces protections s'ajoutent des bénéfices d'organisation, largement reconnus : des environnements reproductibles (le même conteneur en test et en production), des mises à jour par remplacement d'image plutôt que par modification à chaud, et des images minimales qui réduisent la surface d'attaque.

Les principaux risques en cybersécurité

Le guide NIST SP 800-190, publié en 2017, classe les risques par couche. Voici ceux qui concernent le plus souvent Docker.

Quelques risques méritent une attention particulière.

Le démon Docker et son socket

Selon la documentation Docker, le démon s'exécute avec les droits root, sauf en mode rootless, et un accès non autorisé à son API peut permettre de modifier librement le système de fichiers de l'hôte via le partage de volumes. L'OWASP insiste : ne jamais exposer le socket du démon, pas même à un conteneur, car cela équivaut à un accès root illimité à l'hôte.

Les privilèges excessifs

Lancer un conteneur avec des capacités superflues, ou avec l'option --privileged, supprime l'essentiel de l'isolation. L'OWASP recommande de retirer les capacités inutiles et de bloquer l'escalade de privilèges dans le conteneur.

Les ports publiés et le pare-feu

L'OWASP rappelle aussi que Docker peut contourner des règles de pare-feu comme UFW lorsqu'un port est publié sur l'hôte : un service que l'on croyait filtré peut se retrouver exposé.

La chaîne d'approvisionnement

Une image téléchargée depuis un registre public peut contenir des vulnérabilités, des secrets ou du code malveillant. L'ANSSI a publié en décembre 2020 des recommandations pour le déploiement de conteneurs Docker, qui portent sur le déploiement et l'exécution des conteneurs, hors démon et gestion des images. Selon un relais de presse spécialisée, l'agence considère le registre privé et la signature d'images comme des mesures de base.

L'évasion de conteneur

Les vulnérabilités du composant qui lance les conteneurs peuvent permettre de sortir du conteneur. Ainsi, la faille CVE-2024-21626 de runc, connue sous le nom de « Leaky Vessels », pouvait permettre, jusqu'à la version 1.1.11, un accès au système hôte depuis un conteneur via une image ou un Dockerfile malveillant. Elle a été corrigée dans runc 1.1.12, publiée le 31 janvier 2024, d'après Snyk et Palo Alto Networks. Le noyau et le moteur de conteneurs doivent donc être maintenus à jour comme n'importe quel autre composant critique.

La checklist de sécurisation de Docker

Les règles ci-dessous suivent l'ordre de la fiche OWASP Docker Security.

1. Mettre à jour l'hôte et Docker, pour se protéger des failles du noyau et des évasions de conteneur.
2. Ne pas exposer le socket du démon, même aux conteneurs.
3. Définir un utilisateur non privilégié à l'exécution, à la construction de l'image, ou via la redirection d'espaces de noms.
4. Limiter les capacités et éviter --privileged.
5. Empêcher l'escalade de privilèges avec l'option --security-opt=no-new-privileges.
6. Créer des réseaux dédiés plutôt que d'utiliser le réseau par défaut, et prêter attention aux ports publiés.
7. Activer les modules de sécurité Linux : seccomp, AppArmor ou SELinux.
8. Limiter les ressources : mémoire, processeur, descripteurs de fichiers, processus, redémarrages.
9. Monter le système de fichiers et les volumes en lecture seule quand c'est possible.
10. Intégrer l'analyse d'images dans la chaîne d'intégration continue, pour détecter vulnérabilités et mauvaises configurations.
11. Conserver un niveau de journalisation adapté pour la surveillance du démon.
12. Exécuter Docker en mode rootless pour éviter qu'une évasion ne donne un accès root.
13. Gérer les secrets avec Docker Secrets plutôt que dans l'image ou les variables d'environnement.
14. Renforcer la chaîne d'approvisionnement : signature d'images, nomenclature logicielle (SBOM) et registres de confiance.

Un exemple de lancement durci

Voici un exemple de commande qui applique plusieurs de ces règles à un conteneur d'application :

docker run -d --name app \
  --user 10001:10001 \
  --read-only \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --memory 512m --pids-limit 200 \
  mon-image:1.0

Adaptez les valeurs à votre application : certains services ont besoin d'une capacité précise, qu'il faut alors ajouter explicitement plutôt que de conserver toutes les autres.

Le mode rootless en pratique

D'après la documentation Docker, le mode rootless exécute le démon et les conteneurs sans droits root, dans un espace de noms utilisateur, ce qui limite l'impact d'une vulnérabilité du démon ou du moteur d'exécution. Il exige le paquet uidmap et au moins 65 536 identifiants utilisateur et groupe secondaires alloués dans /etc/subuid et /etc/subgid. Vérifiez les limitations propres à votre environnement avant de le déployer.

Analyser ses images

Docker Scout analyse les images, établit une nomenclature logicielle (SBOM) et la compare à une base de vulnérabilités mise à jour en continu. La commande docker scout cves permet de l'utiliser en ligne de commande. Pour comprendre la gravité d'une vulnérabilité détectée, consultez notre guide sur le score CVSS, la base CVE de ForenShield pour retrouver les détails d'un identifiant, et le calculateur CVSS pour qualifier la criticité dans votre contexte.

Les référentiels à connaître

• CIS Docker Benchmark : guide de durcissement détaillé, téléchargeable gratuitement pour un usage non commercial avec un compte CIS.
• Fiche OWASP Docker Security : liste de règles prioritaires.
• NIST SP 800-190 : classification des risques par couche.
• Recommandations de l'ANSSI : bonnes pratiques de déploiement de conteneurs en français.

Ce qu'il faut retenir

Docker apporte une isolation utile, mais elle repose sur la configuration. Trois réflexes limitent l'essentiel des risques : ne jamais exposer le socket, ne pas exécuter les conteneurs avec des privilèges superflus, et surveiller en continu les images et le moteur avec des mises à jour et des analyses régulières.

Sources

• Docker : sécurité du moteur Docker
• Docker : mode rootless
• Docker Scout
• OWASP : Docker Security Cheat Sheet
• NIST : SP 800-190, Application Container Security Guide
• ANSSI : recommandations de sécurité pour le déploiement de conteneurs Docker
• CIS : Docker Benchmark
• Snyk : Leaky Vessels
• Palo Alto Networks : Leaky Vessels