Contactez-nous

Sécuriser le démon Docker

Apprenez les étapes essentielles pour sécuriser le démon Docker (dockerd), y compris le contrôle d'accès à l'API, la configuration sécurisée et les mises à jour.

Introduction : pourquoi la sécurité du démon est primordiale

Le démon Docker (`dockerd`) est le service central qui s'exécute en arrière-plan et gère tous les aspects de l'environnement Docker : il construit les images, lance et arrête les conteneurs, configure les réseaux, gère les volumes, et bien plus encore. Traditionnellement, le démon Docker nécessite des privilèges élevés (il s'exécute en tant que `root` par défaut sur Linux) pour effectuer ses opérations, notamment l'interaction avec le noyau pour créer des namespaces, des cgroups et manipuler les règles réseau (`iptables`).

Cette position privilégiée fait du démon Docker une cible critique. Si un attaquant parvient à obtenir un accès non autorisé à l'API du démon Docker, il obtient essentiellement un contrôle équivalent à `root` sur la machine hôte. Il peut lancer des conteneurs malveillants, monter des répertoires sensibles de l'hôte, exfiltrer des données, ou utiliser l'hôte comme point de pivot pour attaquer d'autres systèmes sur le réseau.

Par conséquent, sécuriser l'accès au démon Docker et sa configuration est l'une des étapes les plus fondamentales et cruciales de la sécurisation globale d'un environnement conteneurisé. Négliger cet aspect revient à laisser la porte principale de votre infrastructure grande ouverte.

Contrôler l'accès à l'API du démon Docker

Le démon Docker expose une API REST que le client Docker (la commande `docker`) utilise pour communiquer avec lui. Par défaut, sur Linux, cette communication se fait via un socket Unix situé à `/var/run/docker.sock`.

Sécurisation du Socket Unix : Par défaut, le socket `docker.sock` appartient à l'utilisateur `root` et au groupe `docker`. Tout utilisateur appartenant au groupe `docker` a un accès complet à l'API Docker, et donc des privilèges équivalents à `root` sur l'hôte. C'est une configuration courante mais potentiellement dangereuse. Limitez strictement l'appartenance au groupe `docker` aux seuls administrateurs de confiance. Ne l'accordez pas aux utilisateurs standards ou aux processus applicatifs. Des alternatives comme l'utilisation de `sudo` pour les commandes Docker individuelles ou des solutions de délégation de privilèges peuvent être envisagées.Exposition sur le Réseau (TCP) : Il est possible de configurer le démon pour écouter sur un port TCP, permettant ainsi une administration à distance. C'est pratique mais extrêmement risqué si ce n'est pas correctement sécurisé. N'exposez jamais le démon Docker sur un port TCP sans authentification et chiffrement robustes. Par défaut, la connexion TCP n'est ni chiffrée ni authentifiée.Sécurisation via TLS (mTLS) : La méthode recommandée pour sécuriser l'accès TCP est d'utiliser TLS pour le chiffrement et l'authentification mutuelle (mTLS). Cela implique :
  1. Générer une autorité de certification (CA) privée.
  2. Générer un certificat et une clé pour le serveur (démon Docker).
  3. Générer un certificat et une clé pour chaque client autorisé.
  4. Configurer le démon Docker pour utiliser TLS et vérifier les certificats clients (options `--tlsverify`, `--tlscacert=ca.pem`, `--tlscert=server-cert.pem`, `--tlskey=server-key.pem` dans le fichier `daemon.json` ou en ligne de commande).
  5. Configurer le client Docker pour utiliser ses certificats et vérifier le certificat serveur (options `--tlsverify`, `--tlscacert=ca.pem`, `--tlscert=cert.pem`, `--tlskey=key.pem` ou variables d'environnement `DOCKER_CERT_PATH`, `DOCKER_TLS_VERIFY`).
Bien que plus complexe à mettre en place, TLS est indispensable pour toute exposition réseau du démon.
// Extrait de daemon.json pour activer TLS
{
  "tls": true,
  "tlsverify": true,
  "tlscacert": "/etc/docker/ca.pem",
  "tlscert": "/etc/docker/server-cert.pem",
  "tlskey": "/etc/docker/server-key.pem",
  "hosts": ["unix:///var/run/docker.sock", "tcp://0.0.0.0:2376"]
}

Configuration sécurisée du démon via `daemon.json`

Le fichier de configuration principal du démon Docker est `/etc/docker/daemon.json`. Il permet de définir de nombreuses options pour renforcer la sécurité et appliquer des bonnes pratiques par défaut.

Voici quelques options de sécurité importantes à considérer :

  • "icc": false : Désactive la communication inter-conteneurs sur le réseau `bridge` par défaut. C'est une bonne pratique, car elle vous oblige à créer explicitement des réseaux définis par l'utilisateur pour les conteneurs qui doivent communiquer, améliorant ainsi la segmentation.
  • "log-driver": "json-file", "log-opts": {"max-size": "10m", "max-file": "3"} : Configure le logging pour éviter que les logs des conteneurs ne remplissent le disque de l'hôte (risque de DoS). D'autres pilotes de log (syslog, journald, fluentd) peuvent être utilisés pour la centralisation.
  • "userns-remap": "default" ou "userns-remap": "your_user" : Active le remappage des espaces de noms utilisateur. C'est une mesure de sécurité puissante qui exécute les processus à l'intérieur du conteneur en tant qu'utilisateur non privilégié sur l'hôte, même s'ils s'exécutent en tant que root dans le conteneur. Cela réduit considérablement l'impact d'une évasion de conteneur. Sa mise en oeuvre nécessite une configuration spécifique des plages UID/GID sur l'hôte.
  • "no-new-privileges": true : Empêche les conteneurs d'acquérir de nouveaux privilèges via les exécutables `setuid` ou `setgid`.
  • "seccomp-profile": "/path/to/custom/profile.json" : Permet de spécifier un profil seccomp personnalisé pour restreindre les appels système autorisés pour les conteneurs (au lieu du profil par défaut déjà restrictif).
  • "selinux-enabled": true ou configuration AppArmor : Assure que les mécanismes de contrôle d'accès obligatoire (MAC) du noyau Linux sont activés et utilisés par Docker pour confiner davantage les conteneurs.
  • "live-restore": true : Permet aux conteneurs de continuer à s'exécuter même si le démon Docker est arrêté ou redémarré (pour des mises à jour, par exemple), améliorant la disponibilité mais nécessitant une attention particulière lors des mises à jour.

Examinez attentivement les options disponibles dans la documentation officielle et adaptez la configuration de votre `daemon.json` pour renforcer la sécurité de votre environnement spécifique.

Utilisation des fonctionnalités de sécurité Linux (Namespaces, Cgroups, Seccomp, MAC)

Le démon Docker s'appuie fortement sur les fonctionnalités de sécurité intégrées au noyau Linux pour isoler les conteneurs. Bien que ces mécanismes s'appliquent principalement à l'exécution des conteneurs, la configuration du démon peut influencer leur utilisation.

Namespaces (Espaces de noms) : Fournissent l'isolation des ressources (PID, réseau, montage, IPC, utilisateur, UTS). Le démon utilise les namespaces pour créer l'environnement isolé du conteneur. L'activation de l'option `userns-remap` (User Namespace) dans le `daemon.json`, comme mentionné précédemment, est une amélioration significative de la sécurité.Cgroups (Control Groups) : Limitent et suivent l'utilisation des ressources (CPU, mémoire, I/O disque, réseau) par les conteneurs. Le démon utilise les cgroups pour appliquer les limites de ressources spécifiées lors du lancement d'un conteneur (options `--memory`, `--cpus`, etc.), ce qui aide à prévenir les attaques par déni de service (DoS) où un conteneur consommerait toutes les ressources de l'hôte.Seccomp (Secure Computing Mode) : Filtre les appels système qu'un processus (et donc un conteneur) est autorisé à effectuer vers le noyau. Docker applique par défaut un profil seccomp assez strict qui bloque de nombreux appels système potentiellement dangereux. Vous pouvez spécifier un profil encore plus restrictif via le `daemon.json` ou lors du lancement d'un conteneur (`--security-opt seccomp=...`).MAC (Mandatory Access Control) : Des systèmes comme SELinux ou AppArmor fournissent une couche supplémentaire de contrôle d'accès obligatoire, définissant des politiques fines sur ce que les conteneurs peuvent faire, même s'ils s'exécutent en tant que root. Si SELinux ou AppArmor sont activés sur l'hôte, le démon Docker les utilisera généralement par défaut pour confiner davantage les conteneurs. Vous pouvez spécifier des profils personnalisés via `--security-opt label=...` (SELinux) ou `--security-opt apparmor=...` (AppArmor).

Mises à jour régulières et surveillance continue

Comme tout logiciel, le démon Docker peut contenir des vulnérabilités qui sont découvertes et corrigées au fil du temps. Il est essentiel de maintenir le moteur Docker à jour en appliquant régulièrement les correctifs de sécurité publiés par Docker Inc. ou votre fournisseur Linux.

Abonnez-vous aux avis de sécurité concernant Docker et planifiez des fenêtres de maintenance pour appliquer les mises à jour. L'option `live-restore` dans `daemon.json` peut aider à minimiser l'impact des redémarrages du démon sur les conteneurs en cours d'exécution.

Enfin, mettez en place une surveillance et un audit de l'activité du démon Docker. Configurez une journalisation appropriée (via `daemon.json`) et centralisez les logs. Surveillez les événements suspects, tels que des tentatives d'accès non autorisées à l'API, des créations ou suppressions inattendues de conteneurs/réseaux/volumes, ou des erreurs indiquant des problèmes de sécurité potentiels. Des outils d'analyse de logs et des systèmes de détection d'intrusion peuvent être intégrés pour une surveillance plus avancée.

Le mode Rootless : vers une sécurité accrue

Une avancée significative pour la sécurité du démon est le mode Rootless. Il permet d'exécuter le démon Docker et les conteneurs en tant qu'utilisateur non privilégié, sans nécessiter les privilèges `root` sur la machine hôte. Cela réduit considérablement la surface d'attaque, car même une compromission complète du démon ou une évasion de conteneur ne donnerait pas à l'attaquant un accès root à l'hôte.

Le mode Rootless utilise des espaces de noms utilisateur (`userns`) pour mapper les UID/GID à l'intérieur du conteneur à des UID/GID non privilégiés sur l'hôte. Sa mise en place est plus complexe que l'installation standard et présente certaines limitations (par exemple, concernant les réseaux ou l'exposition de ports privilégiés < 1024).

Bien qu'il ne soit pas encore universellement adopté et qu'il nécessite une configuration spécifique, le mode Rootless représente une direction prometteuse pour améliorer fondamentalement la sécurité des déploiements Docker, en particulier dans les environnements multi-utilisateurs ou à haut risque. Si la sécurité est votre priorité absolue, explorer et tester le mode Rootless est fortement recommandé.