Origine du microVM chez Docker
En 2015, Docker proposait Docker Toolbox, qui reposait sur VirtualBox. Cette solution introduisait une couche d’hyperviseur complète, avec interface graphique et processus de mise à jour distincts. L’équipe Docker a jugé ces éléments superflus pour un usage quotidien sur macOS et Windows. En s’appuyant sur les bibliothèques Mirage Unikernel, elle a développé un library VMM, c’est‑à‑dire un hyperviseur intégré, minimal et dédié à l’exécution d’un seul système d’exploitation invité.
Évolution du VMM intégré
Le premier prototype, nommé hyperkit, a été intégré dans Docker for Mac dès 2016. Il a ensuite évolué vers Docker VMM, une version plus allégée mais conceptuellement identique. Le noyau et le système de fichiers de la VM s’appuyaient sur le projet LinuxKit, qui fournit une image Linux réduite à l’essentiel. Cette architecture a permis d’isoler le conteneur Docker dans une machine virtuelle dont le code source est contrôlé et auditable.
Implications techniques du modèle microVM
Le recours à une microVM rend le moteur Docker rootless sur toutes les plateformes : le noyau Linux de la VM étant considéré comme non fiable, aucune vulnérabilité Linux (CVE) ne peut affecter directement l’hôte. Le nombre de périphériques exposés est limité, ce qui simplifie l’audit de la surface d’attaque. L’interaction avec les VPN et les politiques réseau est également plus prévisible, car le trafic passe uniquement par les interfaces virtuelles définies dans la VM. Cette configuration a facilité l’ajout ultérieur de fonctionnalités telles que le Registry Access Management.
Docker Sandboxes et usage actuel
En 2026, la même pile microVM alimente Docker Sandboxes, un environnement d’exécution isolé destiné aux agents de code et aux charges de travail sensibles. Le produit se lance via la commande
sbx run claude
