Docker-in-Docker (DinD) vs montage du socket Docker : Avantages et inconvénients

Le besoin : exécuter Docker depuis Docker en CI/CD

Dans les pipelines CI/CD modernes, les agents d'exécution (les machines ou environnements qui exécutent les étapes du pipeline) sont souvent eux-mêmes des conteneurs Docker. Cela offre flexibilité, isolation et reproductibilité pour les tâches du pipeline. Cependant, un besoin courant est d'exécuter des commandes Docker *depuis* cet agent conteneurisé, par exemple pour construire une image (`docker build`) ou lancer des conteneurs pour des tests d'intégration (`docker run`, `docker-compose up`).

Comment un conteneur peut-il interagir avec Docker ? Deux approches principales ont émergé pour répondre à ce besoin, chacune avec ses propres avantages, inconvénients et implications de sécurité importantes : Docker-in-Docker (DinD) et le montage du socket Docker de l'hôte.

Approche 1 : Docker-in-Docker (DinD)

• Isolation : Les conteneurs et images créés via DinD sont entièrement contenus et gérés par le démon Docker *interne*. Ils sont isolés du démon Docker de la machine hôte qui exécute l'agent CI.
• Exigence `--privileged` : Pour fonctionner correctement, le conteneur exécutant le démon DinD (`docker:dind`) nécessite généralement des privilèges étendus sur l'hôte, accordés via l'option `--privileged`. C'est nécessaire pour permettre au démon interne d'effectuer des opérations de bas niveau (montages, gestion réseau, etc.).

• Forte isolation : L'environnement Docker interne est complètement séparé de celui de l'hôte. Cela peut être utile pour éviter les conflits (par exemple, de réseaux) et garantir un état de départ propre pour chaque build.
• Indépendance de l'hôte : Moins dépendant de la configuration spécifique du démon Docker de l'hôte.

• Sécurité Majeure : L'utilisation de `--privileged` est extrêmement dangereuse. Elle désactive la plupart des mécanismes d'isolation du conteneur, donnant potentiellement au processus à l'intérieur un accès quasi-root à la machine hôte. Un exploit dans le démon DinD ou dans un conteneur lancé via DinD pourrait compromettre l'hôte.
• Performance : Peut introduire une surcharge de performance due à l'exécution d'un démon complet en mode virtualisé/conteneurisé.
• Complexité : La configuration peut être plus complexe (gestion du service DinD, interaction entre conteneurs).
• Problèmes de stockage : Des problèmes peuvent survenir avec les pilotes de stockage si le pilote utilisé par DinD est le même que celui de l'hôte (par exemple, overlayfs sur overlayfs), bien que des améliorations aient été apportées.
• Cache d'images séparé : Le cache d'images est propre au démon DinD, il ne partage pas le cache du démon de l'hôte.

Approche 2 : Montage du Socket Docker de l'hôte

• Communication directe avec l'hôte : Toutes les commandes Docker exécutées depuis le conteneur sont en réalité traitées par le démon Docker principal de la machine hôte.
• Pas de démon interne : Seul le client Docker est nécessaire dans le conteneur de l'agent.

• Simplicité : La configuration est généralement plus simple (un seul montage de volume).
• Performance : Les opérations Docker sont exécutées directement par le démon natif de l'hôte, souvent plus performant que DinD.
• Partage du cache d'images : Le conteneur utilise le cache d'images du démon Docker de l'hôte, ce qui peut accélérer les builds si les couches sont déjà présentes sur l'hôte.
• Pas besoin de `--privileged` (généralement) : Le conteneur lui-même n'a pas besoin de privilèges élevés, bien que l'accès au socket accorde des privilèges de fait.

• Sécurité Majeure (différente) : C'est l'inconvénient principal. Donner accès au socket Docker de l'hôte à un conteneur revient essentiellement à lui donner les mêmes privilèges que l'utilisateur exécutant le démon Docker sur l'hôte (souvent `root`). Un processus malveillant dans le conteneur peut :
• Démarrer n'importe quel conteneur sur l'hôte (y compris des conteneurs privilégiés).
• Arrêter, supprimer ou inspecter n'importe quel autre conteneur sur l'hôte (y compris ceux d'autres pipelines ou applications).
• Accéder ou manipuler des volumes Docker sur l'hôte.
• Extraire des informations sensibles via l'API Docker.
• Moins d'isolation : Les conteneurs démarrés et les images construites via cette méthode le sont réellement sur l'hôte, au même niveau que le conteneur de l'agent CI. Il y a un risque de conflits (noms de conteneurs, ports mappés si non aléatoires) et une moins bonne isolation de l'environnement de build par rapport à l'hôte.

DinD vs Socket : Lequel choisir ?

Le choix entre DinD et le montage du socket est un compromis délicat, principalement axé sur la sécurité et l'isolation versus la simplicité et la performance.

Points clés et avertissements de sécurité

Permettre à un conteneur CI/CD d'exécuter des commandes Docker introduit des défis de sécurité. Docker-in-Docker (DinD) offre une meilleure isolation de l'environnement de build mais requiert souvent `--privileged`, ce qui est très dangereux pour l'hôte.

Le montage du socket Docker est plus simple et performant, partage le cache de l'hôte, mais donne au conteneur un contrôle quasi total sur le démon Docker de l'hôte, ce qui est un risque de sécurité majeur si le démon tourne en root.

Aucune des deux méthodes n'est intrinsèquement "sûre" sans précautions. Le choix dépend du contexte, du niveau de confiance dans le code exécuté, de la configuration de l'infrastructure (agents éphémères, Docker rootless sur l'hôte) et de la tolérance au risque.

Pour la seule tâche de construction d'images, envisagez des alternatives sans démon comme Kaniko ou Buildah pour une approche potentiellement plus sécurisée. Evaluez soigneusement les implications de sécurité avant d'implémenter l'une ou l'autre de ces méthodes dans vos pipelines.