Xytherion Tools
Retour au blog
développement13 min de lecture6 juin 2026

Docker en production : sécurité et bonnes pratiques

Sécuriser vos conteneurs Docker : images minimales, utilisateur non-root, secrets, réseaux isolés, scan de vulnérabilités et Dockerfile hardening.

Docker simplifie le déploiement, mais une mauvaise configuration peut exposer des secrets, donner un accès root à l'hôte ou permettre des élévations de privilèges. Ce guide couvre les bonnes pratiques de sécurité Docker en production : images, réseaux, secrets, et hardening des conteneurs.

Pourquoi Docker peut être dangereux par défaut

Par défaut, Docker tourne en root sur l'hôte. Un conteneur compromis avec les mauvais paramètres peut écrire des fichiers sur l'hôte, accéder aux autres conteneurs, ou escalader les privilèges jusqu'au noyau Linux.

  • Le daemon Docker tourne en root — accès au socket = root sur la machine
  • Les images Docker Hub peuvent contenir des malwares ou des CVE connues
  • Les secrets passés en variables d'environnement sont visibles dans docker inspect
  • Les conteneurs partagent le noyau Linux de l'hôte — pas d'isolation complète

1. Images minimales et multi-stage builds

Moins il y a de logiciels dans une image, moins il y a de surface d'attaque. Utilisez des images Alpine ou distroless.

dockerfile
# ❌ Mauvaise pratique — image complète avec build tools en prod
FROM node:20
COPY . .
RUN npm install && npm run build
CMD ["node", "dist/index.js"]

# ✅ Bonne pratique — multi-stage build
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM node:20-alpine AS runner
WORKDIR /app
# Utilisateur non-root
RUN addgroup -g 1001 -S nodejs && adduser -S nextjs -u 1001
COPY --from=builder --chown=nextjs:nodejs /app/dist ./dist
COPY --from=builder --chown=nextjs:nodejs /app/node_modules ./node_modules
USER nextjs
EXPOSE 3000
CMD ["node", "dist/index.js"]

Les images distroless de Google (gcr.io/distroless/nodejs) ne contiennent ni shell ni package manager — une vulnérabilité ne peut pas télécharger d'outils supplémentaires.

2. Ne jamais tourner en root

Créez toujours un utilisateur non-root dans votre Dockerfile et forcez son utilisation.

dockerfile
# Pour une application Python
FROM python:3.12-slim
WORKDIR /app

# Créer un utilisateur dédié
RUN useradd --create-home --shell /bin/bash appuser
COPY --chown=appuser:appuser requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY --chown=appuser:appuser . .

USER appuser
CMD ["python", "app.py"]
bash
# Forcer l'utilisateur non-root au runtime même si le Dockerfile ne le fait pas
docker run --user 1000:1000 mon-image

3. Gestion sécurisée des secrets

Ne jamais passer de secrets (clés API, mots de passe) dans les variables d'environnement Docker — ils sont visibles via 'docker inspect' et dans les logs CI/CD.

yaml
# ❌ Mauvais — secrets en clair dans docker-compose.yml
services:
  app:
    environment:
      - DB_PASSWORD=supersecret123
      - API_KEY=sk-abc123

# ✅ Bonne pratique — Docker Secrets (Swarm) ou fichier .env non versionné
services:
  app:
    environment:
      - DB_PASSWORD_FILE=/run/secrets/db_password
    secrets:
      - db_password

secrets:
  db_password:
    file: ./secrets/db_password.txt
bash
# Alternative avec fichier .env local (jamais committé)
echo "DB_PASSWORD=supersecret123" > .env
echo ".env" >> .gitignore

# Utilisation
docker run --env-file .env mon-image

4. Réseaux Docker isolés

Par défaut, tous les conteneurs sur le réseau bridge peuvent se parler. Créez des réseaux dédiés par tier applicatif.

yaml
services:
  nginx:
    image: nginx:alpine
    networks:
      - frontend
    ports:
      - "443:443"

  app:
    build: .
    networks:
      - frontend
      - backend  # peut parler à nginx ET à la DB

  postgres:
    image: postgres:16-alpine
    networks:
      - backend  # isolé — nginx ne peut pas l'atteindre directement

networks:
  frontend:
  backend:
    internal: true  # pas d'accès Internet depuis ce réseau

5. Limiter les ressources et les capabilities

yaml
services:
  app:
    image: mon-app
    # Limiter les ressources
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: "0.50"

    # Supprimer toutes les capabilities Linux et n'ajouter que ce qui est nécessaire
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE  # seulement si besoin de binder port < 1024

    # Système de fichiers en lecture seule
    read_only: true
    tmpfs:
      - /tmp
      - /var/run

    # Désactiver l'escalade de privilèges
    security_opt:
      - no-new-privileges:true

6. Scanner les images pour les vulnérabilités

Trois outils de référence : Trivy (recommandé, polyvalent), Docker Scout (intégré à Docker Desktop) et Grype (léger et rapide).

bash
# Trivy — scanner open-source (recommandé)
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock   aquasec/trivy image mon-image:latest

# Docker Scout (intégré à Docker Desktop)
docker scout cves mon-image:latest

# Grype — alternative légère
grype mon-image:latest

# Dans une CI/CD GitHub Actions
- name: Scan image
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'mon-image:latest'
    exit-code: '1'
    severity: 'CRITICAL,HIGH'

Intégrez Trivy dans votre pipeline CI/CD et configurez un seuil de rejet (exit-code 1 si CVE CRITICAL détecté). Ainsi, aucune image vulnérable ne peut être déployée en production.

7. Sécuriser l'accès au socket Docker

Le socket Docker (/var/run/docker.sock) est équivalent à un accès root sur la machine. Il ne doit jamais être monté dans un conteneur en production. Alternatives : Podman (rootless par design) ou rootless Docker.

bash
# ❌ Jamais en production — accès root à l'hôte garanti si compromis
docker run -v /var/run/docker.sock:/var/run/docker.sock mon-image

# ✅ Alternatives pour les cas légitimes (CI/CD, monitoring)
# Docker-in-Docker (DinD) avec socket TCP isolé
# Rootless Docker (tourne sans root du tout)
# Podman — alternative rootless par design
bash
# Passer Docker en mode rootless (Linux)
dockerd-rootless-setuptool.sh install
export DOCKER_HOST=unix:///run/user/1000/docker.sock

Sources & références

  1. 1
    Docker — Bonnes pratiques de sécurité (documentation officielle)

    Guide officiel Docker sur les Dockerfiles sécurisés et multi-stage builds

  2. 2
    OWASP — Docker Security Cheat Sheet

    Référence OWASP pour la sécurisation des conteneurs Docker

  3. 3
    Trivy — Documentation officielle

    Scanner de vulnérabilités open-source pour images Docker, systèmes de fichiers et dépôts

  4. 4
    CIS Docker Benchmark

    Référentiel CIS pour l'audit de sécurité des environnements Docker

  5. 5
    Google Distroless — GitHub

    Images de base minimalistes sans shell ni outils système

#docker#conteneurs#sécurité#devops#production

Testez vos configurations

Xytherion Tools propose des outils gratuits pour vérifier vos DNS, auditer votre SSL, tester SPF/DKIM/DMARC et bien plus — directement depuis votre navigateur.

Tous les articles
Docker en production : sécurité et bonnes pratiques — Xytherion Tools