Les configs Docker les plus dangereuses en 2026

Introduction aux Risques des Configs Docker

Comprendre les Risques

Les erreurs de configuration exposent vos conteneurs : ports non protégés, volumes mal restreints, absence d'isolement réseau ou exécution en tant que root sont des vecteurs d'attaque récurrents. Une démarche proactive combine automatisation (scans), politiques (least privilege) et revues humaines régulières.

Checklist rapide :

• Vérifiez les ports exposés
• Limitez et durcissez les volumes montés
• Isoler les conteneurs via des réseaux privés
• Intégrer des scans d'images dans la CI/CD

Exemple d'exécution simple (ne pas exposer un service HTTP sans contrôle d'accès) :

docker run -d -p 80:80 --name webserver nginx

Assurez-vous que le port 80 est filtré par un pare-feu ou provisoirement accessible uniquement via un proxy inverse authentifié.

Configurations Ouvertes au Public

Risques des Configurations Publiques

Rendre un service accessible directement depuis l'internet sans authentification est une erreur courante : bases de données, interfaces d'administration, endpoints API. Même des services internes peuvent devenir une porte d'entrée s'ils sont exposés par inadvertance.

Bonnes pratiques :

• Évitez d'exposer des services sensibles inutilement
• Placez les services internes dans des réseaux privés
• Protégez les endpoints avec un proxy inverse (auth, WAF)
• Automatisez les scans d'exposition (exécution périodique dans CI)

Exécution dans un réseau privé Docker :

docker run -d --network my_network my_app

Cas concret (mini étude) : sur un déploiement e-commerce, un service d'administration UID exposé par erreur a été détecté par un scan automatisé intégré à la CI; l'équipe a appliqué un réseau privé et un proxy, évitant l'exploitation en production.

Utilisation de Privilèges Élevés

Dangers des Privilèges Élevés

Exécuter des conteneurs avec des privilèges root (ou en mode --privileged) étend la surface d'attaque : une compromission du conteneur peut devenir compromission de l'hôte. Limiter les droits appliqués au conteneur est une règle fondamentale.

• Ne pas exécuter les processus d'application en root
• Privilèges minimaux : --user, capabilities réduites
• Appliquer AppArmor/SELinux et seccomp profiles
• Auditer les permissions des volumes

Exécuter un conteneur avec un utilisateur non privilégié :

docker run -d --user 1000:1000 my_app

Cas pratique : migration d'un service monolithique vers conteneur — en changeant l'utilisateur de processus et en appliquant un profile seccomp personnalisé, l'équipe a réduit les vecteurs exploitables observés lors d'un pentest interne.

Mauvaise Gestion des Secrets

Problèmes de stockage et de transmission

Stocker des secrets en clair (fichiers, variables d'environnement non chiffrées, repos publics) est souvent la cause d'incidents. Utilisez des gestionnaires de secrets adaptés et la rotation régulière des clés.

• Ne jamais stocker de secrets en clair dans le code
• Utiliser une solution de gestion des secrets (Docker Secrets, Vault, etc.)
• Automatiser la rotation et l'audit d'accès
• Limiter l'accès via RBAC

Créer un secret Docker (exemple) :

echo \"my_secret_password\" | docker secret create db_password -

Mini-étude : une équipe a remplacé les variables d'environnement sensibles par HashiCorp Vault et intégré la lecture dynamique des secrets via l'init container. Résultat : réduction notable des secrets exposés dans les logs et commits.

Réseaux Non Isolés et Vulnérabilités

Importance de l'isolement réseau

Sans segmentation réseau, une compromission peut se propager horizontalement. Segmentez vos services (front, back, DB) et appliquez des règles strictes de communication entre eux.

• Créer des réseaux Docker personnalisés
• Définir des règles de pare-feu entre segments
• Limiter les communications entre conteneurs
• Surveiller le flux réseau avec un IDS/NSM

Créer un réseau isolé :

docker network create --driver bridge my_custom_network

Cas pratique : lors d'un déploiement microservices, la mise en place d'un réseau par service et l'usage de listes blanches sur les ports ont empêché la latéralisation d'une faille découverte dans un service non critique.

Configurations Réseau Inappropriées

L'utilisation du mode host ou l'exposition non filtrée de services sur des ports par défaut augmentent le risque d'attaque. Préférez des réseaux dédiés et des proxies inverse pour contrôler l'accès.

• Évitez le mode host sauf besoin précis
• Utilisez des réseaux Docker dédiés
• Appliquez des ACL et des règles firewall
• Vérifiez régulièrement les ports exposés

Exemple de création et d'exécution isolée :

docker network create my_custom_network

docker run --network my_custom_network -p 80:80 my_app

Mini-cas : sur un service interne, le passage d'un déploiement en mode bridge avec restriction d'écoute à localhost pour certaines interfaces a éliminé plusieurs sondages non autorisés observés par le monitoring.

Utilisation de Volumes Non Sécurisés

Monter des volumes hôtes avec des permissions larges expose le système de fichiers de l'hôte. Privilégiez les volumes nommés et les montages en lecture seule lorsque l'écriture n'est pas nécessaire.

• Évitez les montages de répertoires racine de l'hôte
• Utilisez des volumes Docker nommés
• Activer le mode :ro quand possible
• Nettoyer et auditer les volumes inutilisés

Commande pour monter un volume en lecture seule :

docker run -v my_data:/data:ro my_app

Exemple opérationnel : un volume hôte monté en mode RW a permis à un attaquant d'implanter un binaire persistant. Après migration vers un volume nommé et règles d'accès restreintes, le vecteur d'attaque a disparu.

Bonnes pratiques pour les Dockerfiles

Le Dockerfile est la première ligne de défense : un Dockerfile propre réduit la surface d'attaque et facilite l'analyse. Appliquez ces règles :

• Multi-stage builds pour réduire la taille et limiter les dépendances runtime
• Exécuter l'application avec un utilisateur non-root : utilisez USER
• Utiliser HEALTHCHECK pour détecter les containers non sains
• Minimiser les couches : grouper les commandes apt / package manager et nettoyer les caches
• Utiliser --chown sur COPY si besoin pour éviter les chmod couteux à l'exécution
• Générer un SBOM et scanner l'image en sortie

Exemple de Dockerfile multi-stage (Node.js, image minimale) :

FROM node:18-alpine AS build

WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --production=false
COPY . ./
RUN npm run build

FROM node:18-alpine AS runtime
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
# Use non-root user
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=5s CMD [ \"/bin/sh\", \"-c\", \"wget -qO- http://localhost:3000/health || exit 1\" ]
CMD [ \"node\", \"dist/index.js\" ]

Commentaires :

• Le build stage contient les outils nécessaires au build (compilation, dépendances de dev) tandis que le runtime stage n'inclut que l'exécutable et les dépendances nécessaires.
• Le HEALTHCHECK permet au runtime d'indiquer aux orchestrateurs qu'un conteneur est défaillant.

Exécution runtime recommandée (durcissement) :

docker run \
  --read-only \
  --user 1000:1000 \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  --security-opt=no-new-privileges \
  --tmpfs /tmp:rw,noexec,nosuid,size=64M \
  --memory=512m \
  --cpus="0.5" \
  myrepo/myapp:stable

Profils de sécurité : AppArmor & SELinux

Au-delà des flags d'exécution, appliquez des politiques OS-level pour contraindre le comportement des conteneurs. Deux approches courantes : AppArmor (Ubuntu, Debian) et SELinux (RHEL, CentOS, Fedora).

AppArmor — exemple minimal

Créer un profil AppArmor basique et l'appliquer au conteneur. Exemple de profil (fichier /etc/apparmor.d/mydocker.profile) :

# AppArmor profile: mydocker.profile
# Deny write access except for /tmp and /var/log/myapp
profile mydocker {
  # include abstractions and basic rules
  # Deny dangerous syscalls via abstractions if present
  file,
  capability,
  network,
  deny /sys/** w,
  deny /proc/sys/** w,
  /tmp/** rw,
  /var/log/myapp/** rw,
  /etc/** r,
  /usr/** r,
  /bin/** r,
  /lib/** r,
  /lib64/** r,
}

Charger le profil et exécuter le conteneur :

sudo apparmor_parser -r /etc/apparmor.d/mydocker.profile
docker run --security-opt apparmor=mydocker myrepo/myapp

SELinux — bonnes pratiques et exemples

Avec SELinux, relabellez les répertoires hôtes et utilisez les options :z ou :Z sur les montages. Exemple :

# Relabel host directory for container access (sane default for containers)
sudo chcon -Rt svirt_sandbox_file_t /opt/myapp/data

# Run container with SELinux label on volume (Z for private)
docker run -v /opt/myapp/data:/data:Z myrepo/myapp

Remarques :

• :z — partager le volume entre plusieurs conteneurs (ajoute le label partagé)
• :Z — créer un label privé pour un seul conteneur (plus sûr)
• Sur les systèmes où SELinux est activé, vérifiez les logs (auditd) pour ajuster les politiques.

Tests et validation : exécutez des containers avec des profils en mode complain avant enforce pour corriger les règles sans bloquer le runtime.

Outils et scanners recommandés

Intégrez des scanners d'images et des outils de posture de sécurité dans vos pipelines CI/CD. Voici une liste d'outils couramment utilisés :

• Trivy (scan d'images et fichiers SBOM) — recommandation : intégrer Trivy dans la CI pour blocage sur CVE critiques.
• Snyk (analyse de dépendances et conteneurs) — rapports et intégrations IDE/CI.
• Anchore / Clair (analyse d'images en profondeur)
• Aqua Security (scan runtime et policies)
• Falco (détection d'anomalies runtime)

Commande d'exemple (Trivy) pour scanner une image dans la CI :

trivy image --severity CRITICAL,HIGH --exit-code 1 myrepo/myimage:latest

Intégration CI (mini-guide) : lancer le scan après le build de l'image, générer un rapport SARIF/HTML, et bloquer le pipeline si des vulnérabilités critiques sont trouvées.