Docker Swarm : Sécuriser un Cluster en Production, 13 Étapes [2026]

Docker Swarm n’a pas disparu. Pendant que Kubernetes accapare les conférences et les offres d’emploi, des milliers d’équipes DevOps continuent de faire tourner leur production sur des clusters Swarm, souvent parce qu’elles n’ont ni le temps ni le besoin de gérer un control plane Kubernetes complet. Avec Docker Engine 29.8.1 (publié le 15 septembre 2026) et Docker Compose 5.5.1 (3 septembre 2026), l’outil reste activement maintenu et embarque une infrastructure de sécurité PKI complète, prête à l’emploi. Ce tutoriel vous montre comment monter un cluster Swarm en production, le sécuriser correctement, et éviter les pièges qui transforment un déploiement simple en incident de sécurité.

On part d’une machine vierge jusqu’à un cluster à trois nœuds avec secrets chiffrés, réseau overlay protégé, rotation de certificats et sauvegarde du journal Raft. Treize étapes, cinq blocs de code testables, et une bonne dose de pièges à éviter parce que la documentation officielle passe vite sur certains détails qui coûtent cher en production.

Pourquoi Docker Swarm reste pertinent en 2026

Docker Swarm mode est intégré directement à Docker Engine depuis 2016, ce qui veut dire qu’il n’y a rien à installer en plus si vous avez déjà Docker. Un cluster complet tient en trois commandes : docker swarm init, docker swarm join, docker stack deploy. Comparé à un cluster Kubernetes autogéré qui exige etcd, un scheduler, un control manager, un kube-apiserver et généralement un CNI à choisir séparément, Swarm ramène la barrière d’entrée à quelques minutes.

La cible naturelle de ce tutoriel, ce sont les petites équipes, les déploiements edge, les environnements où deux à dix nœuds suffisent, et les organisations qui veulent garder une surface opérationnelle réduite. Ce n’est pas un outil pour des plateformes multi-équipes de plusieurs centaines de services : Kubernetes garde l’avantage sur l’écosystème d’opérateurs, les CRD et la richesse du réseau (CNI, service mesh). Mais pour un cluster de production de taille modeste, Swarm fait le travail avec beaucoup moins de pièces mobiles à sécuriser.

Selon la documentation officielle Docker, la PKI intégrée au mode Swarm permet de déployer un système d’orchestration de conteneurs de façon sécurisée sans configuration TLS manuelle (docs.docker.com). Chaque nœud applique l’authentification mutuelle TLS et le chiffrement pour sécuriser les communications avec les autres nœuds du cluster. C’est ce socle de sécurité par défaut qui distingue Swarm d’un simple `docker run` répété sur plusieurs machines.

Prérequis : versions et matériel nécessaires

Avant de commencer, vérifiez que votre environnement correspond à ces versions. Le tutoriel a été testé avec les versions suivantes, actuelles au 25 septembre 2026. Pour suivre le cycle de support de Docker Engine et savoir quand une version majeure sort du support de sécurité, consultez le calendrier de fin de vie tenu à jour par la communauté (endoflife.date).

Vous aurez aussi besoin d’un accès root ou sudo sur chaque machine, d’une connectivité réseau directe entre les nœuds (pas de NAT symétrique bloquant), et idéalement d’un client SSH configuré avec des clés pour administrer les trois nœuds sans ressaisir de mot de passe à chaque commande.

Étape 1 : installer Docker Engine 29.8.1 sur les trois nœuds

Sur chacune des trois machines (un manager, deux workers pour cet exemple), installez Docker Engine via le dépôt officiel. Évitez les paquets `docker.io` fournis par les dépôts génériques de distribution, souvent en retard de plusieurs versions.

curl -fsSL https://get.docker.com -o install-docker.sh
sudo sh install-docker.sh

# Vérifier la version installée
docker version --format '{{.Server.Version}}'
# Sortie attendue : 29.8.1

sudo systemctl enable docker
sudo systemctl start docker

# Ajouter votre utilisateur au groupe docker (évite sudo à chaque commande)
sudo usermod -aG docker $USER
newgrp docker

Répétez l’opération sur les trois machines. Notez leurs adresses IP privées, vous en aurez besoin pour l’initialisation du cluster. Si vous êtes sur un cloud provider (AWS, Azure, OVHcloud, Scaleway), utilisez l’IP privée du réseau interne, jamais l’IP publique, pour le trafic Swarm.

Étape 2 : configurer le pare-feu et les ports réseau

Docker Swarm a besoin de trois ports ouverts entre tous les nœuds du cluster. Les oublier est la cause numéro un des clusters qui refusent de se former.

# Sur chaque nœud, avec ufw
sudo ufw allow 2377/tcp
sudo ufw allow 7946/tcp
sudo ufw allow 7946/udp
sudo ufw allow 4789/udp
sudo ufw reload

# Vérification rapide de connectivité entre nœuds
nc -zv 10.0.0.2 2377

Si vous êtes derrière un groupe de sécurité cloud (Security Group AWS, NSG Azure), ouvrez ces mêmes ports uniquement entre les IP privées des nœuds du cluster, jamais vers 0.0.0.0/0. Le port 2377 exposé publiquement est une porte d’entrée directe vers l’API de gestion du cluster.

Étape 3 : initialiser le manager avec docker swarm init

Sur la machine que vous voulez désigner comme premier manager, lancez l’initialisation en spécifiant explicitement l’adresse IP à annoncer aux autres nœuds.

docker swarm init --advertise-addr 10.0.0.1

# Sortie attendue :
# Swarm initialized: current node (x8k3j...) is now a manager.
#
# To add a worker to this swarm, run the following command:
#     docker swarm join --token SWMTKN-1-abc123... 10.0.0.1:2377
#
# To add a manager to this swarm, run 'docker swarm join-token manager'
# and follow the instructions.

Ce moment déclenche la création automatique d’une autorité de certification (CA) racine sur ce manager. C’est la base de toute la sécurité du cluster : chaque nœud qui rejoindra le Swarm recevra un certificat signé par cette CA, et toutes les communications de gestion passeront ensuite par TLS mutuel sans configuration manuelle de votre part.

Étape 4 : comprendre la PKI et la rotation des certificats

C’est l’étape que la plupart des tutoriels sautent, et c’est justement celle qui distingue un cluster de test d’un cluster de production. Par défaut, chaque nœud du Swarm renouvelle son certificat tous les trois mois environ, soit une fenêtre de rotation d’environ 90 jours, comme documenté par Docker (docs.docker.com).

Pour un environnement à exigences de sécurité plus strictes, vous pouvez réduire ce délai. La documentation officielle indique une valeur minimale d’une heure.

# Réduire la durée de vie des certificats à 24h
docker swarm update --cert-expiry 24h

# Vérifier la configuration actuelle du cluster
docker swarm inspect --format '{{.Spec.CAConfig.NodeCertExpiry}}'
# Sortie attendue : 24h0m0s

Une rotation plus courte réduit la fenêtre d’exploitation d’un certificat volé, mais augmente la dépendance à la disponibilité des managers et à la synchronisation d’horloge (NTP) entre les nœuds. Pour un cluster de production classique, gardez la valeur par défaut sauf exigence de conformité spécifique (ANSSI, ISO 27001) imposant une rotation plus fréquente.

Étape 5 : joindre les workers et managers au cluster

Récupérez le jeton de jonction généré à l’étape 3, ou régénérez-le à tout moment. Docker génère deux jetons distincts : un pour les workers, un pour les managers. Chacun contient l’empreinte du certificat de la CA racine ainsi qu’un secret aléatoire.

# Sur le manager : récupérer les tokens
docker swarm join-token worker
docker swarm join-token manager

# Sur chaque machine worker :
docker swarm join --token SWMTKN-1-abc123... 10.0.0.1:2377

# Vérifier depuis le manager que tous les nœuds sont bien listés
docker node ls
# ID          HOSTNAME   STATUS   AVAILABILITY   MANAGER STATUS
# x8k3j *     manager1   Ready    Active         Leader
# a7f2k       worker1    Ready    Active
# b9d4m       worker2    Ready    Active

Pour un vrai cluster de production, ajoutez au moins deux managers supplémentaires (donc trois au total) afin de conserver un quorum Raft en cas de panne d’un manager. Ne dépassez jamais un nombre pair de managers : cinq est un bon plafond au-delà duquel la latence de consensus commence à se faire sentir.

Traitez les jetons de jonction comme des identifiants sensibles. Ils ne doivent jamais atterrir dans un ticket, un dépôt Git, une capture d’écran partagée ou un journal CI. Si un jeton a fuité, faites-le tourner immédiatement.

# Faire tourner un jeton compromis
docker swarm join-token --rotate worker
docker swarm join-token --rotate manager

Étape 6 : créer un réseau overlay chiffré

C’est le point le plus mal compris de la sécurité Swarm. Le trafic de contrôle (les commandes que vous envoyez, l’état du cluster) est protégé par TLS mutuel de bout en bout. Mais le trafic applicatif entre conteneurs sur des hôtes différents, lui, n’est pas chiffré automatiquement simplement parce que le réseau est de type overlay, comme le précise la documentation Docker (docs.docker.com).

Autrement dit : les données que votre application échange entre deux conteneurs sur deux machines différentes circulent en clair sur le réseau overlay, sauf si vous activez explicitement le chiffrement.

# Créer un réseau overlay avec chiffrement du trafic applicatif
docker network create \
  --driver overlay \
  --opt encrypted \
  --attachable \
  reseau-securise

# Vérifier que le chiffrement est actif
docker network inspect reseau-securise --format '{{.Options}}'
# Sortie attendue : map[com.docker.network.driver.overlay.vxlanid_list:4096 encrypted:]

Le chiffrement overlay ajoute une couche IPsec entre les hôtes, ce qui a un coût CPU mesurable sur du trafic à fort débit. Testez avec votre charge réelle avant de généraliser cette option à tous vos réseaux, en particulier si vous manipulez de gros volumes de données entre services.

Étape 7 : gérer les secrets Docker de façon sécurisée

Les secrets Swarm (mots de passe, clés API, certificats) sont transmis au manager via une connexion TLS mutuelle et stockés dans le journal Raft chiffré. Ils sont ensuite exposés aux conteneurs sous forme de fichiers montés dans /run/secrets/, jamais comme variables d’environnement, ce qui réduit le risque d’exposition accidentelle dans des logs applicatifs ou un dump de process.

# Créer un secret à partir d'une entrée standard
printf 'MonMotDePasseSecret123' | docker secret create db_password -

# Lister les secrets existants (le contenu n'est jamais affiché)
docker secret ls

# Utiliser le secret dans un service
docker service create \
  --name database \
  --secret db_password \
  --env POSTGRES_PASSWORD_FILE=/run/secrets/db_password \
  postgres:latest

Un secret n’est accessible qu’aux tâches auxquelles il est explicitement attribué. Gardez à l’esprit qu’un manager compromis peut accéder à l’état sensible complet du cluster, et que rien n’empêche une application mal codée de journaliser le contenu d’un secret qu’elle vient de lire. Protégez aussi vos sauvegardes : elles contiennent le journal Raft, donc potentiellement vos secrets chiffrés avec la clé de chiffrement du cluster, comme le détaille la documentation officielle sur la gestion des données sensibles (docs.docker.com).

Pour faire tourner un secret existant sans interrompre le service (par exemple après la rotation d’un mot de passe de base de données), créez une nouvelle version sous un nom différent, mettez à jour le service pour qu’il pointe vers ce nouveau secret, puis supprimez l’ancien une fois la bascule confirmée.

# Rotation d'un secret sans interruption
printf 'NouveauMotDePasse456' | docker secret create db_password_v2 -

docker service update \
  --secret-rm db_password \
  --secret-add source=db_password_v2,target=db_password \
  database

# Une fois la bascule confirmée, supprimer l'ancien secret
docker secret rm db_password

Étape 8 : déployer une stack complète avec Docker Compose

Un fichier Compose au format stack (v3.9 ou supérieur) permet de décrire l’ensemble de votre application et de la déployer d’un coup sur le cluster.

version: "3.9"

services:
  web:
    image: nginx:1.27-alpine
    ports:
      - "80:80"
    networks:
      - reseau-securise
    deploy:
      replicas: 3
      update_config:
        parallelism: 1
        delay: 10s
        order: start-first
      restart_policy:
        condition: on-failure
        max_attempts: 3

  api:
    image: monregistry.io/api:1.4.2
    secrets:
      - db_password
    networks:
      - reseau-securise
    deploy:
      replicas: 2

networks:
  reseau-securise:
    external: true

secrets:
  db_password:
    external: true

docker stack deploy -c docker-compose.yml monapp

# Vérifier l'état des services
docker stack services monapp
# ID       NAME          MODE         REPLICAS   IMAGE
# a1b2c3   monapp_web    replicated   3/3        nginx:1.27-alpine
# d4e5f6   monapp_api    replicated   2/2        monregistry.io/api:1.4.2

Notez l’usage de order: start-first dans la politique de mise à jour : Swarm démarre la nouvelle version d’une tâche avant d’arrêter l’ancienne, ce qui évite une coupure de service pendant un déploiement, à condition que votre application supporte de tourner en deux versions simultanément le temps de la transition.

Étape 9 : configurer healthchecks et rolling updates sans interruption

Sans healthcheck, Swarm considère qu’un conteneur qui démarre est immédiatement sain, même s’il n’est pas encore prêt à recevoir du trafic. Ajoutez un healthcheck explicite pour que le scheduler attende réellement que le service réponde avant de router du trafic dessus.

services:
  api:
    image: monregistry.io/api:1.4.2
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/healthz"]
      interval: 15s
      timeout: 5s
      retries: 3
      start_period: 20s
    deploy:
      update_config:
        parallelism: 1
        delay: 10s
        failure_action: rollback
        order: start-first

Le paramètre failure_action: rollback est celui qui vous sauve en production : si la nouvelle version échoue au healthcheck, Swarm revient automatiquement à la version précédente sans attendre une intervention manuelle. Testez ce comportement volontairement en déployant une image cassée avant de compter dessus le jour où ça compte vraiment.

Étape 10 : activer l’autolock et sauvegarder le journal Raft

Le journal Raft utilisé par les managers pour répliquer l’état du cluster est chiffré au repos par défaut. Mais la clé de déchiffrement est chargée en mémoire au démarrage de chaque manager, ce qui veut dire qu’un redémarrage la recharge automatiquement, sans intervention. C’est pratique, mais ça veut aussi dire qu’un disque de manager volé, même arrêté, peut potentiellement être remis en route ailleurs et redémarrer avec sa clé.

L’autolock répond à ce scénario en exigeant une clé de déverrouillage manuelle après chaque redémarrage d’un manager.

# Activer l'autolock sur le cluster
docker swarm update --autolock=true
# Sortie : affiche la clé de déverrouillage, à stocker dans un coffre-fort
# (Vault, 1Password, ou un HSM) – jamais en clair sur le disque du serveur

# Après un redémarrage de manager, débloquer avec :
docker swarm unlock
# (demande la clé de déverrouillage)

L’autolock introduit une exigence opérationnelle réelle : sans la clé, un manager redémarré reste bloqué et ne rejoint pas le cluster, comme le rappelle la documentation Docker sur le verrouillage du cluster (docs.docker.com). Documentez clairement où se trouve cette clé et qui y a accès avant de l’activer sur un cluster déjà en production, sous peine de vous retrouver bloqué dehors après un simple redémarrage planifié.

# Sauvegarder l'état du cluster (à faire sur un manager, service arrêté)
sudo systemctl stop docker
sudo tar -czvf swarm-backup-$(date +%Y%m%d).tar.gz /var/lib/docker/swarm
sudo systemctl start docker

Étape 11 : mettre en place la supervision du cluster

Sans interface graphique, diagnostiquer un problème sur Swarm demande de multiplier les commandes docker service ps et docker service logs. Portainer reste l’option la plus rapide à déployer pour une vue d’ensemble du cluster.

docker volume create portainer_data

docker service create \
  --name portainer \
  --publish 9443:9443 \
  --constraint 'node.role == manager' \
  --mount type=bind,src=/var/run/docker.sock,dst=/var/run/docker.sock \
  --mount type=volume,src=portainer_data,dst=/data \
  portainer/portainer-ce:latest

La contrainte node.role == manager est importante : Portainer a besoin d’accéder au socket Docker du manager pour lire l’état complet du cluster. Ne le déployez jamais sur un worker exposé publiquement, et protégez son port 9443 derrière un reverse proxy avec authentification si l’accès n’est pas limité à un VPN interne.

Étape 12 : durcir le cluster pour la production

Une fois le cluster fonctionnel, plusieurs mesures de durcissement supplémentaires réduisent la surface d’attaque. Elles s’inspirent des recommandations du CIS Docker Benchmark (cisecurity.org), la référence pour l’audit de sécurité des environnements Docker. Ce référentiel couvre à la fois la configuration du démon, les permissions des fichiers de configuration, l’isolation des conteneurs et les pratiques de build d’images. Il vaut la peine d’être parcouru une fois le cluster stable, même partiellement, plutôt que d’appliquer une checklist générique sans contexte.

• Limitez les workers qui peuvent exécuter des conteneurs privilégiés avec des labels et des contraintes de placement explicites.
• Désactivez l’accès direct au socket Docker (/var/run/docker.sock) depuis les conteneurs applicatifs, sauf nécessité absolue documentée.
• Configurez des quotas de ressources (--limit-cpu, --limit-memory) sur chaque service pour éviter qu’un conteneur compromis ou buggé n’épuise les ressources du nœud.
• Activez le scan d’images avant déploiement avec docker scout cves pour détecter les vulnérabilités connues dans vos images de base.
• Séparez les réseaux overlay par fonction (frontend, backend, base de données) plutôt que d’utiliser un réseau unique pour tous les services.

# Limiter les ressources d'un service
docker service update \
  --limit-cpu 0.5 \
  --limit-memory 512M \
  monapp_api

# Scanner les vulnérabilités d'une image avant déploiement
docker scout cves monregistry.io/api:1.4.2

Étape 13 : tester la résilience face à la panne d’un manager

Un cluster de production n’est pas testé tant que vous n’avez pas simulé la panne d’un manager. Avec trois managers, le cluster doit continuer à fonctionner normalement après la perte d’un seul, le quorum Raft restant satisfait avec deux managers sur trois.

# Simuler la panne : arrêter Docker sur un manager non-leader
sudo systemctl stop docker

# Depuis un autre manager, vérifier que le cluster reste opérationnel
docker node ls
# Le nœud arrêté apparaît en "Down", les autres restent "Ready"

# Redémarrer le nœud et vérifier qu'il rejoint proprement le cluster
sudo systemctl start docker
docker swarm unlock   # si l'autolock est actif
docker node ls

Si vous perdez deux managers sur trois simultanément, le quorum Raft n’est plus satisfait et le cluster passe en lecture seule : impossible de créer de nouveaux services ou de modifier l’état existant tant qu’un quorum n’est pas restauré. C’est une raison supplémentaire de répartir vos managers sur des zones de disponibilité distinctes plutôt que sur le même rack physique.

Sécuriser l’accès distant à l’API Docker

La PKI intégrée à Swarm protège la communication entre les nœuds du cluster, mais elle ne protège pas automatiquement l’API Docker elle-même si vous l’exposez sur le réseau pour l’administrer à distance depuis votre poste de travail ou un pipeline CI/CD. Par défaut, le démon Docker (dockerd) n’écoute que sur un socket Unix local, ce qui est le réglage le plus sûr. Si vous devez absolument l’exposer en TCP, faites-le uniquement derrière son propre certificat TLS, distinct de la PKI Swarm.

# Générer une CA et des certificats dédiés à l'API Docker (à faire une fois)
openssl genrsa -aes256 -out ca-key.pem 4096
openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem

# Configurer le démon pour exiger un certificat client valide
sudo tee /etc/docker/daemon.json <

# .github/workflows/deploy.yml
name: Deploy to Swarm
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build and push image
        run: |
          docker build -t monregistry.io/api:${{ github.sha }} .
          docker push monregistry.io/api:${{ github.sha }}
      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SWARM_MANAGER_HOST }}
          username: deploy
          key: ${{ secrets.SWARM_SSH_KEY }}
          script: |
            docker service update \
              --image monregistry.io/api:${{ github.sha }} \
              monapp_api

# Configurer un pilote de journalisation syslog pour un service
docker service create \
  --name api \
  --log-driver syslog \
  --log-opt syslog-address=udp://log-collector.internal:514 \
  monregistry.io/api:1.4.2

# 1. Sur le nœud manager
docker swarm init --advertise-addr 10.0.0.1
docker swarm update --cert-expiry 24h
docker network create --driver overlay --opt encrypted --attachable reseau-securise
printf 'MonMotDePasseSecret123' | docker secret create db_password -

# 2. Récupérer et distribuer le token worker aux deux autres machines
docker swarm join-token -q worker

# 3. Sur worker1 et worker2
docker swarm join --token  10.0.0.1:2377

# 4. Retour sur le manager : déployer la stack
docker stack deploy -c docker-compose.yml monapp

# 5. Vérifier l'ensemble
docker node ls
docker stack services monapp
docker stack ps monapp