Sécurité des conteneurs Docker : limiter les privilèges, protéger les secrets et contrôler les images

Un conteneur n’est pas une machine virtuelle : il partage le noyau de l’hôte. Si l’application qu’il contient est compromise et qu’il tourne avec trop de droits, l’attaquant peut atteindre le serveur entier, puis les autres conteneurs. 2025 et 2026 l’ont rappelé avec plusieurs failles d’évasion de conteneur, dont « Copy Fail », une faille du noyau Linux inscrite au catalogue des vulnérabilités activement exploitées de la CISA en mai 2026. Voici les réglages qui réduisent concrètement le risque, applicables dès aujourd’hui à vos fichiers Docker Compose.

L’essentiel en 30 secondes

• Jamais de conteneur --privileged, jamais de socket Docker monté dans un conteneur exposé.
• Exécuter en utilisateur non root, retirer toutes les capacités Linux, interdire l’élévation de privilèges, système de fichiers en lecture seule.
• Les secrets ne vont ni dans l’image, ni dans les variables d’environnement visibles : utilisez des fichiers montés (secrets Docker).
• Images minimales, épinglées par empreinte, analysées et, idéalement, signées.
• Mettez à jour le noyau de l’hôte, Docker Engine et runc : les protections des conteneurs ne compensent pas une faille du noyau.

Ce que l’actualité a appris

Pour « Copy Fail », en attendant le noyau corrigé, les distributions où le module est chargeable (Debian, Ubuntu) peuvent le bloquer : ajouter install algif_aead /bin/false dans un fichier de /etc/modprobe.d/ puis rmmod algif_aead. Sur la famille Red Hat, où il est intégré au noyau, Red Hat documente un paramètre de démarrage.

Un fichier Compose durci

services:
  app:
    image: registre.exemple.fr/app@sha256:<empreinte-vérifiée>
    user: "10001:10001"
    read_only: true
    tmpfs:
      - /tmp
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    pids_limit: 200
    mem_limit: 512m
    ports:
      - "127.0.0.1:8080:8080"
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password

secrets:
  db_password:
    file: ./secrets/db_password.txt

• user : l’application ne tourne pas en root dans le conteneur.
• read_only et tmpfs : un attaquant ne peut pas modifier les fichiers de l’application ; seul /tmp est inscriptible, en mémoire.
• cap_drop: ALL : aucune capacité Linux ; ajoutez uniquement celles réellement nécessaires avec cap_add.
• no-new-privileges : empêche l’élévation via des binaires setuid.
• pids_limit et mem_limit : limitent l’impact d’un emballement ou d’une attaque par épuisement.
• 127.0.0.1 devant le port publié : le service n’est accessible que via le proxy inverse local.

Le piège du pare-feu

Docker écrit ses propres règles iptables : un port publié sans préciser d’adresse ("8080:8080") est joignable depuis Internet même si UFW semble le bloquer. Publiez sur 127.0.0.1 ou sur l’adresse interne, et contrôlez depuis l’extérieur ce qui est réellement ouvert.

Les interdits

Des images saines

• Constructions multi-étapes : les outils de compilation restent dans l’étape de construction, l’image finale ne contient que l’exécutable.
• Bases minimales (images « slim », distroless, Alpine) : moins de paquets, moins de vulnérabilités.
• Pour les secrets nécessaires à la construction, utilisez les secrets BuildKit (RUN --mount=type=secret), qui ne sont pas conservés dans les couches.
• Analyse systématique avec un scanner, génération d’un SBOM, et vérification de signature avec Cosign.

Durcir l’hôte

• Mode rootless de Docker (ou Podman) quand c’est possible, sinon remappage des utilisateurs (userns-remap).
• Profils seccomp et AppArmor ou SELinux actifs (ceux par défaut, au minimum).
• Mises à jour régulières du noyau, de Docker Engine, de containerd et de runc.
• Audit périodique avec Docker Bench for Security, qui vérifie les recommandations du CIS.
• Accès SSH à l’hôte sécurisé (voir sécuriser SSH) et journaux centralisés.

Questions fréquentes

Rootless Docker est-il compatible avec tout ?

La plupart des applications fonctionnent, mais certaines limites existent (ports inférieurs à 1024, certains pilotes réseau ou de stockage). Testez avant de basculer la production.

Les variables d’environnement sont-elles vraiment dangereuses pour les secrets ?

Elles sont visibles par quiconque peut inspecter le conteneur, elles apparaissent parfois dans les journaux d’erreur et sont héritées par les processus enfants. Un fichier monté en lecture seule est préférable.

Comment savoir quelles capacités ajouter ?

Partez de zéro, lancez l’application, et ajoutez uniquement ce que les erreurs réclament (par exemple NET_BIND_SERVICE pour écouter sur le port 80 sans être root).

Faut-il passer à Kubernetes pour être plus sûr ?

Non : Kubernetes ajoute des mécanismes, mais aussi beaucoup de complexité. Un hôte Docker bien durci suffit à de nombreuses PME.

Sources

• Linuxfabrik, vulnérabilité noyau « Copy Fail » (CVE-2026-31431), avril 2026, mis à jour en mai 2026.
• Ubuntu, avis USN-7851-1 sur les failles de runc, novembre 2025.
• Docker, documentation sur la sécurité de Docker Engine.
• CISA, catalogue des vulnérabilités exploitées (KEV).

Besoin d’un accompagnement ?

MPCÂBLE Solutions Informatiques (MPCSI) accompagne particuliers, entreprises, associations et collectivités depuis Gaudiès, en Ariège : sur site en Occitanie, principalement dans un rayon de 40 km (Pamiers, Foix, Mirepoix, Saverdun, Castelnaudary), et à distance partout en France. Nous auditons et durcissons vos serveurs de conteneurs dans le cadre de notre infogérance. Demandez un devis gratuit ou appelez le 05 32 42 99 98.