Docker : Plateforme de Conteneurisation et Sécurité 2026

Docker est la plateforme de conteneurisation qui a popularisé en 2013 l'usage des conteneurs Linux dans le développement logiciel, le DevOps et le cloud computing moderne. Conçu initialement par dotCloud (renommé Docker Inc. en 2013) autour des primitives Linux cgroups, namespaces et UnionFS, Docker fournit aujourd'hui un écosystème complet : un moteur d'exécution (Docker Engine), une CLI (docker), un format d'image standardisé conforme aux spécifications OCI (Open Container Initiative), un registre public (Docker Hub) hébergeant plus de 15 millions d'images, un orchestrateur léger (Docker Swarm), un compositeur multi-services (Docker Compose) et une suite desktop pour macOS, Windows et Linux (Docker Desktop). En 2026, après douze années d'évolution et une transition douloureuse vers une licence commerciale Docker Desktop en 2021, Docker reste l'outil incontournable pour empaqueter une application avec ses dépendances en un artefact reproductible, mais coexiste désormais avec un écosystème mature d'alternatives open source comme Podman, containerd, Buildah, Rancher Desktop et OrbStack. Ce guide entity-first détaille l'architecture interne (dockerd, containerd, runc), les bonnes pratiques Dockerfile, la sécurité (rootless mode, capabilities, seccomp, AppArmor), les attaques typiques (container escape, supply chain), les outils de hardening (Trivy, Cosign, distroless, Wolfi), la conformité (CIS Docker Benchmark, NIST SP 800-190) et les cas d'usage en production cloud-native.

Définition : qu'est-ce que Docker ?

Docker est une plateforme open source de conteneurisation qui automatise le déploiement d'applications à l'intérieur de conteneurs logiciels légers et portables. Un conteneur Docker isole un processus et son environnement (binaires, librairies, fichiers de configuration) en utilisant les fonctionnalités natives du noyau Linux : namespaces (isolation du PID, du réseau, des points de montage, des utilisateurs et de l'IPC), cgroups (limitation des ressources CPU, mémoire, I/O) et UnionFS (overlay2 par défaut, qui permet l'empilement de couches d'images en lecture seule sur une couche d'écriture).

Docker fournit plusieurs composants distincts mais souvent confondus :

• Docker Engine : le moteur core open source (Apache 2.0) qui inclut le daemon dockerd, l'API REST et le client CLI. Tourne nativement sur Linux
• Docker Desktop : l'application graphique pour macOS, Windows et Linux qui embarque une VM Linux (LinuxKit ou WSL2), Kubernetes optionnel et une UI ; payante pour les entreprises depuis 2021
• Docker Compose : outil de définition multi-conteneurs via un fichier YAML docker-compose.yml
• Docker Hub : registre public d'images opéré par Docker Inc., monétisé via abonnements Pro/Team/Business
• Docker Swarm : orchestrateur natif intégré au Docker Engine, en mode legacy mais toujours supporté
• BuildKit : moteur de build moderne, parallélisé, avec cache distribué (intégré depuis Docker 18.09, par défaut depuis 23.0)

Les images Docker sont conformes à la spécification OCI Image Spec publiée en 2017 par l'Open Container Initiative, ce qui garantit qu'une image construite avec Docker peut être exécutée par n'importe quel runtime conforme : containerd, CRI-O, Podman, gVisor, Kata Containers. Cette standardisation est cruciale pour l'écosystème cloud-native et la portabilité des charges entre Docker, Kubernetes et les serverless containers (AWS Fargate, Google Cloud Run, Azure Container Apps).

Histoire : de dotCloud 2013 à containerd 2026

L'histoire de Docker commence chez dotCloud, une PaaS française créée en 2010 par Solomon Hykes, Sebastien Pahl et Kamel Founadi. Pour orchestrer leurs propres conteneurs LXC en interne, ils développent un outil baptisé "Docker" qu'ils présentent en mars 2013 lors d'une conférence PyCon devenue mythique : "The future of Linux containers" — vidéo qui dépasse aujourd'hui les 700 000 vues. La démo dure 5 minutes, le code est publié sur GitHub le même jour, et l'effervescence est immédiate. dotCloud est rebaptisée Docker Inc. fin 2013, lève des fonds importants et bascule entièrement sur le projet Docker.

Chronologie clé :

• Mars 2013 : annonce publique de Docker, basé initialement sur LXC
• 2014 : Docker 0.9 remplace LXC par libcontainer, sa propre librairie d'exécution écrite en Go (qui deviendra runc)
• Juin 2015 : création de l'Open Container Initiative (OCI) avec Linux Foundation, Docker, CoreOS, Google, Microsoft, Red Hat et IBM. Docker donne sa libcontainer pour devenir runc, runtime de référence
• 2016 : sortie de Docker Swarm Mode intégré au Docker Engine
• 2017 : Docker extrait son daemon de runtime de bas niveau dans un projet séparé donné à la CNCF : containerd
• 2018 : Docker Enterprise Edition est revendue à Mirantis ; Docker Inc. se recentre sur les développeurs (Docker Desktop, Hub, Compose)
• Décembre 2020 : Kubernetes annonce la dépréciation du dockershim dans v1.20
• Août 2021 : changement de licence Docker Desktop — payant pour entreprises de plus de 250 employés ou plus de 10 M$ de CA
• Mai 2022 : Kubernetes v1.24 supprime définitivement le dockershim
• 2023-2025 : montée en puissance de Podman, Rancher Desktop, OrbStack, Colima comme alternatives gratuites à Docker Desktop
• 2026 : Docker Engine 27.x stabilise les User Namespaces activés par défaut, BuildKit 0.16 améliore le cache distribué et Docker Scout devient l'offre commerciale phare de Docker Inc.

Cette trajectoire illustre une dynamique fréquente dans l'open source : un acteur popularise une technologie, puis l'écosystème la standardise et l'absorbe progressivement (Kubernetes pour l'orchestration, containerd pour le runtime), tandis que l'éditeur d'origine pivote vers la couche développeur et la monétisation.

Architecture : CLI, API, dockerd, containerd, runc

Docker repose sur une architecture en couches, souvent invisible pour l'utilisateur final mais fondamentale à comprendre pour la sécurité et la performance.

1. Docker CLI (docker)

Le client en ligne de commande envoie des requêtes HTTP REST au daemon via une socket Unix locale (/var/run/docker.sock) ou un endpoint TCP distant. La CLI est un binaire léger, écrit en Go, qui ne fait aucun travail de bas niveau lui-même.

2. Docker Engine API

L'API REST exposée par le daemon (versionnée, par défaut sur la socket Unix) accepte les commandes build, run, pull, push, exec, etc. Cette API est aussi consommée par Docker Compose, Portainer, Rancher et de nombreux outils tiers.

3. dockerd (le daemon)

Le daemon principal Docker tourne en root par défaut (sauf en mode rootless), gère le cycle de vie des conteneurs, des images, des réseaux (bridge, host, overlay, macvlan), des volumes et des secrets Swarm. Il délègue l'exécution des conteneurs à containerd via gRPC.

4. containerd

Daemon de runtime de plus bas niveau, projet CNCF graduated depuis 2019, écrit en Go. containerd gère la récupération d'images, leur stockage (snapshots), la transmission au runtime OCI et la collecte des métriques. Il peut aussi être utilisé directement par Kubernetes (sans Docker) via l'interface CRI (Container Runtime Interface).

5. runc

Le runtime OCI de référence : un binaire ligne de commande qui crée et démarre effectivement un conteneur en invoquant les appels système clone(), unshare(), setns(), pivot_root() et configure les cgroups, capabilities, seccomp et AppArmor. C'est runc qui constitue la frontière de sécurité réelle entre l'hôte et le conteneur — d'où l'importance critique des CVE qui le ciblent (CVE-2024-21626, CVE-2019-5736).

6. Composants additionnels

• BuildKit / buildkitd : moteur de build moderne, parallélisé, avec cache distribué et support des secrets de build et SSH agent forwarding
• containerd-shim : un processus shim par conteneur qui survit aux redémarrages de containerd
• libnetwork : la stack réseau de Docker (création de bridges docker0, iptables/nftables NAT, overlay VXLAN pour Swarm)

Pour visualiser cette chaîne : la commande docker run nginx traverse CLI → API REST → dockerd → containerd → containerd-shim → runc → kernel Linux. Chaque saut introduit un point de défaillance potentiel et une surface d'attaque distincte. La récente CVE-2026-34040 (authz bypass dans Docker Engine) illustre par exemple comment un défaut au niveau de l'API peut compromettre la séparation hôte/conteneur.

Concepts fondamentaux : Image, Container, Volume, Network, Dockerfile

Image

Une image Docker est un template immuable en lecture seule contenant un système de fichiers en couches, des métadonnées (variables d'environnement, point d'entrée, ports exposés, utilisateur d'exécution) et un manifeste OCI. Chaque couche correspond à une instruction du Dockerfile (RUN, COPY, ADD) et est identifiée par un hash SHA256. Les images sont identifiées par repository:tag ou par leur digest immutable (repository@sha256:...).

Container

Un conteneur est une instance en cours d'exécution d'une image, avec une couche d'écriture supplémentaire (Copy-on-Write). Plusieurs conteneurs peuvent partager la même image en lecture seule, ce qui économise de l'espace disque et du temps de démarrage.

Volume

Un volume est un mécanisme de persistance des données en dehors du cycle de vie du conteneur. Trois types : bind mounts (chemin hôte direct), named volumes (gérés par Docker dans /var/lib/docker/volumes/), tmpfs mounts (en mémoire). Les volumes sont essentiels pour les bases de données, les logs et les artefacts persistants.

Network

Docker crée par défaut trois réseaux : bridge (réseau virtuel docker0 avec NAT), host (partage la stack réseau de l'hôte) et none (pas de réseau). Pour Swarm, le réseau overlay permet la communication multi-hôtes via VXLAN encapsulé. Les user-defined bridges apportent en plus la résolution DNS automatique entre conteneurs.

Dockerfile

Un fichier texte décrivant les instructions de construction d'une image. Format ligne par ligne avec des instructions standardisées : FROM, RUN, COPY, ADD, ENV, EXPOSE, CMD, ENTRYPOINT, USER, WORKDIR, ARG, HEALTHCHECK, VOLUME, LABEL. Chaque instruction crée une nouvelle couche d'image.

Dockerfile : bonnes pratiques 2026

Un Dockerfile mal conçu produit des images obèses, lentes à construire et vulnérables. Les bonnes pratiques 2026 incluent :

1. Image de base minimale

Préférer alpine, distroless, scratch ou Wolfi (Chainguard) à ubuntu ou debian. Une image Go statique sur scratch peut peser 5-10 Mo contre 200+ Mo sur Ubuntu.

2. Multi-stage builds

Séparer le stage de build (avec compilateur, outils, sources) du stage runtime (binaire seul). Exemple :

FROM golang:1.23 AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o server .

FROM gcr.io/distroless/static:nonroot
COPY --from=builder /app/server /
USER nonroot:nonroot
ENTRYPOINT ["/server"]

3. .dockerignore

Exclure .git/, node_modules/, *.env, tests/, docs/ pour réduire le contexte de build et éviter les fuites de secrets.

4. USER non-root

Toujours définir USER avec un UID >1000 (ou nonroot sur distroless). Ne jamais laisser un conteneur tourner en root par défaut.

5. Pin des versions

Utiliser FROM nginx:1.27.3-alpine et non nginx:latest. Encore mieux : pinner par digest SHA256 pour une reproductibilité absolue.

6. Combiner RUN

Réduire le nombre de couches en chaînant les commandes avec && et nettoyer les caches APT/APK dans la même instruction (apt-get clean && rm -rf /var/lib/apt/lists/*).

7. Scan de vulnérabilités

Intégrer Trivy, Grype ou Docker Scout dans le pipeline CI pour bloquer les images contenant des CVE critiques. Voir notre guide complet Sécurité des conteneurs : scanning et hardening.

8. Healthcheck

Définir HEALTHCHECK pour permettre à Docker (et aux orchestrateurs) de détecter automatiquement les conteneurs en mauvais état.

Docker Hub et registres privés

Le registre est le service qui stocke et distribue les images Docker. Docker Hub est le registre public officiel hébergé par Docker Inc., il contient à la fois des images Official Images maintenues par Docker (nginx, redis, postgres, etc.), des images Verified Publishers (certifiées par les éditeurs eux-mêmes : Bitnami, MongoDB, Elastic) et des dizaines de millions d'images communautaires.

Limitations Docker Hub gratuites :

• Rate limits anonymous : 100 pulls par 6 heures par IP
• Rate limits authenticated : 200 pulls par 6 heures (compte gratuit)
• Plans payants : Pro (250 pulls/jour), Team, Business

Alternatives en 2026 :

• GHCR (GitHub Container Registry) : intégré gratuitement à GitHub, illimité pour les repos publics
• Harbor (CNCF graduated) : registre on-premises avec scan, signing Cosign, RBAC
• AWS ECR : Elastic Container Registry, intégré à IAM
• Azure ACR : Azure Container Registry, géo-réplication
• Google GAR : Google Artifact Registry (ex-GCR)
• Quay.io (Red Hat) : registre commercial avec Clair scan natif
• Distribution (registry:2) : implémentation de référence open source du protocole OCI

Le format de distribution est lui-même standardisé via la OCI Distribution Spec, ce qui rend les registres interopérables : une image poussée sur ECR peut être tirée par Podman, Kubernetes via containerd, ou Buildah sans difficulté.

Docker Compose : orchestration multi-services locale

Docker Compose permet de définir une stack multi-conteneurs dans un fichier YAML docker-compose.yml et de la démarrer avec docker compose up. C'est l'outil de prédilection pour le développement local et les déploiements simples mono-hôte.

Exemple minimal :

services:
  web:
    image: nginx:1.27-alpine
    ports:
      - "8080:80"
    depends_on:
      - api
  api:
    build: ./api
    environment:
      DATABASE_URL: postgres://db:5432/app
  db:
    image: postgres:16-alpine
    volumes:
      - dbdata:/var/lib/postgresql/data
volumes:
  dbdata:

Compose gère automatiquement la création d'un réseau bridge dédié, la résolution DNS entre services par leur nom, le chaînage de dépendances et la gestion des volumes. Depuis Compose v2 (intégré au plugin docker compose en remplacement de docker-compose Python), Compose est devenu un citoyen first-class du Docker Engine.

Limites de Compose : pas de haute disponibilité (mono-hôte), pas de mise à l'échelle automatique, pas de rolling updates avancés. Pour la production multi-hôtes, il faut basculer vers Swarm ou Kubernetes.

Docker Swarm : orchestration native legacy

Docker Swarm (Swarm Mode) est l'orchestrateur natif intégré au Docker Engine depuis 2016. Il transforme un groupe de Docker Engines en un cluster cohérent avec un plan de contrôle distribué (Raft consensus), des secrets chiffrés, un réseau overlay multi-hôte et un load-balancing intégré (Routing Mesh).

Comparaison Swarm vs Kubernetes :

Critère	Docker Swarm	Kubernetes
Courbe d'apprentissage	Très douce	Raide
Setup	docker swarm init	Kubeadm, Talos, distributions managées
Écosystème	Limité	CNCF (150+ projets)
Auto-scaling	Manuel	HPA, VPA, Cluster Autoscaler
Adoption en 2026	En déclin (legacy)	Standard de facto

Swarm reste pertinent pour les petits clusters (3-10 nœuds), les équipes sans expertise Kubernetes et les déploiements edge simples. Mirantis (qui a racheté Docker Enterprise) maintient Swarm en mode maintenance depuis 2020 mais l'avenir est clairement à Kubernetes.

Docker Desktop : licence commerciale et alternatives

Docker Desktop est l'application graphique pour macOS, Windows et Linux qui fournit aux développeurs un environnement Docker complet sans avoir à installer manuellement Docker Engine sur une VM Linux. Elle embarque LinuxKit (sur macOS) ou WSL2 (sur Windows), un cluster Kubernetes optionnel, une UI de gestion d'images/conteneurs/volumes et une intégration extensions.

En août 2021, Docker Inc. a annoncé un changement majeur de licence : Docker Desktop devient payant pour les entreprises de plus de 250 employés ou réalisant plus de 10 millions de dollars de chiffre d'affaires. Les plans : Pro (5 $/mois/utilisateur), Team (9 $/mois), Business (24 $/mois). Cette décision a déclenché une vague de migration vers des alternatives :

• Podman Desktop (Red Hat) : interface desktop pour Podman, gratuit, support Kubernetes Kind
• Rancher Desktop (SUSE) : bundle K3s + containerd ou dockerd, gratuit open source
• OrbStack (macOS only) : performances supérieures à Docker Desktop, gratuit pour usage personnel
• Colima (CLI, macOS/Linux) : VM minimaliste avec containerd ou docker, 100% open source
• Lima (macOS) : VM Linux générique, base de Colima
• Finch (AWS) : alternative open source basée sur nerdctl + containerd

Pour les équipes développement, le choix se fait souvent entre la praticité de Docker Desktop (UI raffinée, intégration IDE) et les économies des alternatives. Pour les CI/CD, Docker Engine en standalone reste la référence.

Sécurité Docker : rootless, capabilities, seccomp, AppArmor

La sécurité Docker repose sur plusieurs couches de défense en profondeur :

1. Mode rootless

Depuis Docker 20.10, le daemon peut tourner sans privilèges root via dockerd-rootless.sh. Le conteneur s'exécute alors dans un user namespace isolé : un UID 0 dans le conteneur correspond à un UID non-privilégié sur l'hôte. Recommandé pour les workloads sensibles, mais avec des limitations (pas de --net=host, pas de ports <1024 sans capabilities).

2. Protection de la Docker socket

La socket /var/run/docker.sock donne un accès root équivalent à l'hôte. Toute exposition (montage dans un conteneur, exposition TCP non-TLS) est équivalente à donner les clefs root. Bonnes pratiques : ne jamais monter la socket dans un conteneur sauf en lecture seule via un proxy contrôlé (docker-socket-proxy de Tecnativa), et exposer l'API en TCP uniquement avec mTLS.

3. Linux capabilities

Docker drop par défaut la plupart des capabilities Linux et n'en garde qu'une douzaine (CAP_CHOWN, CAP_NET_BIND_SERVICE, etc.). Bonne pratique : --cap-drop=ALL puis --cap-add uniquement les capabilities nécessaires. À éviter absolument : CAP_SYS_ADMIN (root équivalent), CAP_NET_ADMIN, CAP_SYS_PTRACE.

4. Profils seccomp

Docker applique par défaut un profil seccomp qui bloque environ 60 syscalls dangereux (kexec_load, mount, ptrace, etc.). Possibilité de fournir un profil custom JSON via --security-opt seccomp=profile.json.

5. AppArmor / SELinux

Sur Ubuntu/Debian, Docker active automatiquement le profil AppArmor docker-default. Sur RHEL/Fedora avec SELinux, l'option --security-opt label=type:container_t applique les contraintes MAC. Personnalisation possible avec des profils dédiés par application.

6. --read-only et --no-new-privileges

Lancer un conteneur avec un filesystem en lecture seule (--read-only) plus un tmpfs pour les chemins nécessaires en écriture. Le flag --security-opt no-new-privileges:true empêche l'élévation de privilèges via setuid.

7. Docker Bench Security

Script officiel Docker Inc. (docker/docker-bench-security) qui audite une installation Docker contre le CIS Docker Benchmark (>140 checks).

Attaques typiques sur Docker

Les conteneurs Docker mal configurés constituent une cible privilégiée pour les attaquants. Les vecteurs courants :

1. Container escape via mount du Docker socket

Un conteneur avec /var/run/docker.sock monté peut lancer un conteneur privilégié sur l'hôte et obtenir un shell root. Une simple commande docker run -v /:/host alpine chroot /host depuis le conteneur compromis donne un accès complet à l'hôte.

2. Mode --privileged

Le flag --privileged donne toutes les capabilities, désactive les profils seccomp/AppArmor et expose tous les devices. Un attaquant dans un conteneur privileged peut monter /dev/sda, lire les disques de l'hôte, charger des modules kernel et compromettre la machine. À bannir en production, sauf cas spécifique (Docker-in-Docker pour CI).

3. Capabilities dangereuses

CAP_SYS_ADMIN et CAP_DAC_READ_SEARCH permettent des évasions documentées (notamment via cgroup release_agent, attaque Notary de 2019).

4. Vulnérabilités runtime

Les CVE critiques sur runc et Docker Engine sont rares mais critiques :

• CVE-2019-5736 (runc) : escape via /proc/self/exe
• CVE-2024-21626 (runc) : "Leaky Vessels" — fuite de file descriptor permettant l'évasion
• CVE-2026-34040 : authz bypass dans Docker Engine — voir notre analyse détaillée

5. Supply chain : images compromises

Docker Hub a été régulièrement utilisé pour distribuer des images malveillantes (cryptomining, backdoors). Recherches Aqua/Sysdig 2024 : plus de 1600 images malveillantes identifiées. Mitigations : Cosign signing, SBOM CycloneDX, vérification de l'éditeur, scan systématique avec Trivy.

6. Détection runtime

Pour détecter les comportements anormaux dans les conteneurs en production, déployer Falco qui analyse les syscalls via eBPF et alerte sur les patterns suspects (shell dans un conteneur, modification de /etc, container escape attempts).

Outils sécurité de l'écosystème Docker

L'écosystème de sécurité Docker en 2026 est riche :

Outil	Catégorie	Modèle
Trivy (Aqua)	Scan vulnérabilités, IaC, secrets, SBOM	Open source
Grype (Anchore)	Scan vulnérabilités	Open source
Snyk Container	Scan + remédiation	SaaS commercial
Docker Scout	Scan + Docker Hub integration	Commercial Docker Inc.
Anchore Engine / Enterprise	Scan + policy engine	Open source + Commercial
Aqua Platform	Plateforme CNAPP complète	Commercial
Clair (Quay)	Scan vulnérabilités	Open source
Cosign (Sigstore)	Signature d'images	Open source
Falco (Sysdig)	Détection runtime via eBPF	Open source
Tracee (Aqua)	Détection runtime via eBPF	Open source

Cosign mérite une mention spéciale : il permet de signer cryptographiquement une image OCI et de stocker la signature dans le registre lui-même. Combiné à Rekor (transparency log) et Fulcio (CA OIDC), il forme la stack Sigstore qui garantit la provenance et l'intégrité des images.

Image hardening : distroless, Wolfi, Alpine, scratch

Le hardening d'image Docker consiste à réduire la surface d'attaque en limitant le contenu à l'essentiel :

scratch

Image vide totale (0 octet de base). Utilisée pour les binaires statiques (Go, Rust). Aucun shell, aucun outil — un attaquant qui obtient l'exécution de code n'a rien sur quoi s'appuyer.

Distroless (Google)

Images publiées par Google sur gcr.io/distroless/ qui contiennent uniquement le runtime de l'application (libc, libssl) et pas de shell, pas d'apt, pas de busybox. Variantes : static, base, java, nodejs, python3.

Alpine Linux

Distribution minimaliste basée sur musl libc et BusyBox, image de base ~5 Mo. Très populaire mais musl peut poser des problèmes de compatibilité avec certaines libs C compilées contre glibc.

Wolfi (Chainguard)

Distribution conçue pour le cloud-native, basée sur glibc, sans aucune CVE héritée. Les Chainguard Images sont signées par défaut, livrées avec SBOM et reconstruction quotidienne. Modèle commercial en plus de l'OSS.

Comparatif tailles

• scratch + Go binary : 5-10 Mo
• distroless static : 2 Mo (sans le binaire)
• alpine:3.20 : 5 Mo
• wolfi-base : 8 Mo
• debian:slim : 75 Mo
• ubuntu:24.04 : 80 Mo

Une réduction de 75 Mo à 5 Mo représente non seulement un gain en performance (pull, démarrage) mais surtout une réduction massive de la surface d'attaque : moins de paquets = moins de CVE.

Containerd vs Docker : la dépréciation de dockershim

Un des tournants majeurs de l'histoire récente de Docker concerne sa relation avec Kubernetes. Initialement, Kubernetes utilisait Docker comme runtime par défaut via une couche d'adaptation appelée dockershim, intégrée à kubelet. Cette couche traduisait les appels CRI (Container Runtime Interface) en appels Docker API.

Le problème : Docker est un monolithe complet incluant CLI, daemon, builder, registre. Kubernetes n'a besoin que de la partie runtime de bas niveau. Le dockershim ajoutait donc de la complexité, des bugs et un coût de maintenance pour le projet Kubernetes — d'autant plus que containerd (extrait de Docker en 2017) implémentait nativement CRI.

Calendrier :

• Décembre 2020 : Kubernetes v1.20 dépréciе dockershim avec un message d'avertissement
• Mai 2022 : Kubernetes v1.24 supprime dockershim
• Conséquence : les clusters Kubernetes utilisent désormais directement containerd (par défaut) ou CRI-O (Red Hat) comme runtime

Important : les images Docker continuent de fonctionner sur Kubernetes — elles sont conformes à OCI Image Spec et donc lisibles par containerd. Seul le daemon Docker a disparu des nœuds Kubernetes. Les développeurs continuent d'utiliser docker build ou docker buildx pour produire des images, et kubectl apply pour les déployer.

Conformité : CIS Docker Benchmark, NIST SP 800-190, PCI-DSS

La conformité réglementaire des conteneurs s'appuie sur plusieurs référentiels :

CIS Docker Benchmark

Publié par le Center for Internet Security, ce benchmark v1.6 (2024) couvre plus de 140 contrôles répartis en : Host Configuration, Docker Daemon, Docker Daemon Configuration Files, Container Images, Container Runtime, Docker Security Operations, Docker Swarm Configuration. Audit automatisé avec docker-bench-security ou Trivy --compliance docker-cis.

NIST SP 800-190

"Application Container Security Guide" publié par le NIST en 2017. Cinq risques majeurs : compromise de l'image, du registre, de l'orchestrateur, du conteneur en runtime et de l'OS hôte. Constitue la base technique du référentiel FedRAMP pour les conteneurs.

PCI-DSS et conteneurs

PCI-DSS v4.0 (2024) inclut des exigences spécifiques aux environnements conteneurisés, notamment 6.4.1 (segmentation), 6.4.2 (isolation des CDE), 11.5.1 (file integrity monitoring) et 10.4 (audit logs centralisés). En pratique : interdiction de mode privileged, segmentation réseau via NetworkPolicies, scan d'images quotidien, signing Cosign obligatoire.

Autres référentiels

• NSA/CISA Kubernetes Hardening Guide (mais s'applique aussi à Docker)
• NIST SP 800-204D : sécurité de la supply chain DevSecOps
• SLSA (Supply-chain Levels for Software Artifacts) : niveau 3 requis pour la production sensible

Pour les organisations soumises à NIS2, DORA ou ANSSI II 901, l'audit complet d'un pipeline CI/CD conteneurisé devient un prérequis : voir notre guide Audit sécurité CI/CD : SAST, DAST, SCA et notre offre Audit sécurité Kubernetes.

Cas d'usage de Docker en 2026

1. Développement local

Le cas d'usage historique : reproduire l'environnement de production sur le poste développeur. Docker Compose orchestre la base de données, le cache, le message broker et l'application en quelques lignes de YAML. Économise des journées de "ça marche chez moi".

2. CI/CD

GitLab CI, GitHub Actions, Jenkins, CircleCI utilisent massivement Docker pour exécuter chaque étape de build et de test dans un conteneur isolé. Le pattern Docker-in-Docker (DinD) permet aussi de construire des images dans un conteneur de CI.

3. Production stateless

Microservices, APIs REST, frontends SPA : toute application stateless se déploie idéalement en conteneur. Avec Kubernetes, AWS Fargate, Google Cloud Run ou Azure Container Apps, le cycle build → push → deploy se réduit à quelques secondes.

4. Edge computing

K3s, MicroK8s ou Docker Swarm sur des Raspberry Pi, des passerelles industrielles ou des points de vente. Format conteneur léger + mises à jour atomiques + observabilité standardisée = idéal pour le edge.

5. Data Science / ML

Reproductibilité des environnements Python complexes (CUDA, TensorFlow, PyTorch). JupyterHub déploie un conteneur par utilisateur. Kubeflow et MLflow s'appuient sur Docker pour les pipelines ML.

6. Bases de données et stateful (avec précaution)

Possible mais nécessite des opérateurs Kubernetes spécialisés (CloudNativePG, Strimzi, MongoDB Operator) et des volumes persistants gérés (CSI). À éviter en production sans expertise.

Limites et inconvénients de Docker

1. Sécurité par défaut modeste

Docker n'est pas une frontière de sécurité aussi solide qu'une VM. L'isolation repose sur les namespaces Linux, qui partagent le kernel hôte. Un kernel exploit (rare mais possible) permet l'escape. Pour les workloads multi-tenants ou sensibles : gVisor (sandboxing user-space) ou Kata Containers (micro-VM) sont préférables.

2. Licence Docker Desktop

La monétisation de Docker Desktop a fragmenté l'écosystème. Beaucoup d'équipes ont migré vers Podman/Rancher Desktop avec un coût de transition non négligeable.

3. Pas un orchestrateur production-grade

Docker seul (sans Swarm) n'est pas adapté à la production multi-hôtes. Swarm lui-même est en mode maintenance. La voie royale est Kubernetes, mais avec sa complexité.

4. Image bloat

Sans bonnes pratiques (multi-stage, distroless), les images deviennent obèses (1-2 Go), lentes à pull et truffées de CVE.

5. Stockage et networking sur Docker Desktop macOS/Windows

Performance I/O dégradée par la VM intermédiaire (LinuxKit, WSL2). OrbStack et Podman avec Apple Virtualization Framework offrent de meilleures performances sur Apple Silicon.

6. Logs et observabilité

Le driver de logs JSON par défaut (json-file) ne fait pas de rotation et peut saturer le disque. Production : driver journald, fluentd ou export direct vers Loki/Elasticsearch.

FAQ Docker

Docker vs Podman : quelles différences ?

Podman (Red Hat) est une alternative drop-in à Docker : la commande podman a une syntaxe quasi identique à docker, et les images OCI sont compatibles. Différences clés : Podman est daemonless (pas de daemon central, chaque conteneur est un processus enfant de l'utilisateur), rootless par défaut (sans configuration), et utilise systemd pour la supervision. Pas de Swarm équivalent côté Podman, mais podman play kube exécute des manifests Kubernetes localement. Choisir Podman pour la sécurité et l'intégration RHEL/Fedora ; rester sur Docker pour l'écosystème Compose et l'expérience développeur historique.

Docker Desktop est-il toujours gratuit ?

Docker Desktop est gratuit pour usage personnel, étudiant, éducatif et pour les petites entreprises (moins de 250 employés ET moins de 10 millions de dollars de chiffre d'affaires). Au-delà, un abonnement Pro/Team/Business est requis depuis août 2021. Docker Engine (le daemon) reste lui sous Apache 2.0, gratuit et open source.

Comment savoir si une image Docker est vulnérable ?

Utiliser un scanner de vulnérabilités : trivy image nginx:latest ou docker scout cves nginx:latest liste les CVE détectées dans les paquets OS et les dépendances applicatives. Pour aller plus loin, vérifier la signature Cosign, examiner le SBOM (Software Bill of Materials) et privilégier les images officielles ou Verified Publishers. Voir aussi notre guide Sécurité des conteneurs : scanning et hardening.

Pourquoi le Docker socket est-il dangereux ?

La socket /var/run/docker.sock permet de communiquer avec le daemon dockerd qui tourne en root. Toute personne ou processus ayant accès à cette socket peut lancer un conteneur privileged, monter le filesystem hôte (-v /:/host) et obtenir un shell root sur la machine. Ne jamais monter la socket dans un conteneur "à la légère" (Portainer, Watchtower, Traefik nécessitent des précautions) ; utiliser un proxy comme tecnativa/docker-socket-proxy qui filtre les endpoints autorisés.

Peut-on utiliser Kubernetes sans Docker ?

Oui, c'est même la norme depuis Kubernetes v1.24 (mai 2022) qui a supprimé le dockershim. Kubernetes utilise désormais containerd (par défaut sur EKS, AKS, GKE) ou CRI-O (par défaut sur OpenShift) comme runtime. Les images Docker restent compatibles car elles respectent la spec OCI. Les développeurs continuent à utiliser docker build pour les construire, mais le moteur Docker n'est plus présent sur les nœuds Kubernetes.

Quelle différence entre docker, containerd et runc ?

docker est la couche utilisateur (CLI + daemon haut niveau) avec UX, builder, registry pull, networking, volumes. containerd est le daemon de runtime de niveau intermédiaire qui gère les images, les snapshots et le cycle de vie des conteneurs (CNCF graduated). runc est le runtime OCI bas niveau qui appelle effectivement les syscalls Linux pour créer un conteneur. La chaîne d'appel est : docker → containerd → runc → kernel.

Liens approfondis

• CVE-2026-34040 : authz bypass dans Docker Engine — analyse technique
• Kubernetes : orchestrateur de conteneurs CNCF
• Trivy : scanner de vulnérabilités cloud-native
• Falco : détection runtime cloud-native CNCF
• Sécurité des conteneurs : scanning et hardening
• Audit sécurité pipeline CI/CD : SAST, DAST, SCA
• Audit sécurité Kubernetes par Ayinedjimi Consultants
• Site officiel Docker Inc.
• Documentation officielle Docker
• Code source Docker Engine (projet Moby) sur GitHub
• Open Container Initiative (OCI)
• CIS Docker Benchmark