Sécuriser Docker : images, secrets, rootless et socket

Sécuriser Docker, c'est protéger trois choses : l'hôte (qui ne doit jamais tomber à cause d'un conteneur), les images (qui ne doivent contenir ni faille connue ni secret) et les conteneurs en marche (qui ne doivent avoir que les droits dont ils ont besoin). Ce chapitre décrit les risques propres aux conteneurs, explique pourquoi le socket Docker est la pièce la plus sensible, durcit un conteneur, analyse les images avec Trivy et Docker Scout, gère les secrets, puis présente le mode rootless.

Les risques d'un hôte Docker

Le socket Docker : la clé de l'hôte

Le démon tourne en root et obéit à quiconque peut écrire sur son socket /var/run/docker.sock. Or demander au démon « lance un conteneur qui monte la racine de l'hôte » est une requête parfaitement normale pour lui. Accès au socket = root sur l'hôte. Trois situations courantes en découlent :

• les membres du groupe docker sont des root sans mot de passe (chapitre 2) ;
• monter le socket dans un conteneur (-v /var/run/docker.sock:/var/run/docker.sock), comme le demandent Traefik, Portainer, certains agents de supervision ou de CI, donne l'hôte à ce conteneur : si une faille le compromet, l'attaquant tient l'hôte. Le monter avec :ro ne change rien : :ro empêche de modifier le fichier socket, pas d'envoyer des requêtes à l'API à travers lui ;
• exposer l'API du démon sur le réseau (port TCP 2375, sans chiffrement ni authentification) revient à offrir l'hôte à tout le réseau : des robots parcourent Internet à la recherche de ce port ouvert pour y lancer des conteneurs de minage de cryptomonnaie.

Les parades :

Durcir un conteneur

Chaque conteneur ne doit avoir que les droits dont il a besoin. Voici le service api de sorbier-frais, durci :

services:
  api:
    image: ghcr.io/sorbier/sorbier-frais:2.4.0
    user: "1000:1000"
    read_only: true
    tmpfs:
      - /tmp
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    pids_limit: 200
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: "1.0"

Et ce qu'il ne faut jamais faire sans une raison précise et documentée :

Analyser les images avec Trivy et Docker Scout

Une image contient un système de base et des dépendances, chacun avec ses failles connues. Un scanner d'images liste les paquets de l'image (son SBOM, la nomenclature logicielle) et les compare aux bases de vulnérabilités publiques.

Trivy, outil libre d'Aqua Security, s'installe sur un poste ou un serveur depuis le dépôt de son éditeur, ou s'utilise en conteneur. Analyse l'image de l'API en ne gardant que les failles graves pour lesquelles un correctif existe :

trivy image --severity HIGH,CRITICAL --ignore-unfixed ghcr.io/sorbier/sorbier-frais:2.4.0

Le rapport donne, pour chaque faille, le paquet concerné (Library), l'identifiant CVE (Vulnerability), la gravité (Severity), la version installée et la version qui corrige (Fixed Version). Avec --exit-code 1, Trivy se termine en erreur s'il trouve quelque chose : c'est ce qui fait échouer un pipeline (chapitre 12). Trivy cherche aussi les secrets oubliés dans les couches, et trivy config . vérifie les Dockerfile (conteneur en root, étiquette latest, ADD d'une URL…). Il n'analyse pas les fichiers compose.yaml : ceux-là se relisent avec la liste des réflexes de sécurité de l'aide-mémoire.

Docker Scout est intégré à Docker Desktop ; sur un serveur Linux avec Docker Engine, son extension de la commande docker ne fait pas partie des paquets du chapitre 2 et s'installe à part (dépôt GitHub docker/scout-cli). Il demande aussi un compte Docker (docker login) :

docker scout quickview ghcr.io/sorbier/sorbier-frais:2.4.0
docker scout cves --only-severity critical,high ghcr.io/sorbier/sorbier-frais:2.4.0
docker scout recommendations ghcr.io/sorbier/sorbier-frais:2.4.0

quickview résume le nombre de failles par gravité, en distinguant celles qui viennent de l'image de base ; cves les liste ; recommendations propose une image de base plus récente ou plus légère.

Que faire d'un rapport ?

1. Mettre à jour l'image de base et reconstruire : la plupart des failles viennent du système de base et disparaissent avec une image récente.
2. Mettre à jour les dépendances de l'application (npm audit, Dependabot).
3. Réduire l'image : slim, alpine ou image durcie (chapitre 4). Moins de paquets, moins de failles.
4. Pour une faille sans correctif, évaluer si le paquet est réellement utilisé, documenter l'acceptation du risque, et surveiller.

Les secrets

Un secret (mot de passe, clé d'API, clé privée) ne doit apparaître ni dans l'image, ni dans le dépôt Git, ni dans les variables d'environnement si on peut l'éviter. Les variables d'environnement sont en effet lisibles par docker inspect, transmises aux processus enfants, et souvent recopiées dans les journaux d'erreur.

Les secrets Compose sont détaillés et mis en œuvre au chapitre 9 : un fichier par secret sur l'hôte, lisible seulement par root et par l'utilisateur du conteneur, déclaré sous la clé secrets: et lu par l'application dans /run/secrets/. Les images officielles de MySQL, MariaDB et PostgreSQL acceptent les variables terminées par _FILE pour lire leurs mots de passe ainsi.

Le mode rootless

En mode rootless, le démon Docker et les conteneurs tournent sous un utilisateur ordinaire, grâce aux espaces de noms utilisateurs : le root d'un conteneur correspond, sur l'hôte, à un numéro d'utilisateur sans aucun privilège. Une évasion de conteneur ne donne alors que les droits de cet utilisateur, et l'accès au socket n'est plus un accès root.

Installation pour un utilisateur dédié, svc-gestion, sur un hôte où Docker Engine est installé :

sudo apt install uidmap docker-ce-rootless-extras
sudo loginctl enable-linger svc-gestion

Puis, connecté en tant que svc-gestion (par une vraie session, ssh par exemple, pas su) :

dockerd-rootless-setuptool.sh install
systemctl --user enable --now docker
docker info --format '{{.SecurityOptions}}'

Le script crée un service systemd propre à l'utilisateur et un contexte rootless pour la commande docker. loginctl enable-linger permet au service de démarrer avec la machine, sans session ouverte. docker info doit afficher rootless parmi les options de sécurité. L'utilisateur a besoin d'au moins 65 536 identifiants subordonnés dans /etc/subuid et /etc/subgid (créés automatiquement pour les nouveaux comptes sur Debian).

Les limites à connaître :

Garder l'ensemble à jour

Les références : CIS et ANSSI

Deux références pour aller plus loin et justifier tes choix dans un dossier d'épreuve :

• le CIS Docker Benchmark, une liste de contrôles détaillés (configuration de l'hôte, du démon, des images, des conteneurs), que l'outil libre Docker Bench for Security vérifie automatiquement ;
• la fiche technique de l'ANSSI « Recommandations de sécurité relatives au déploiement de conteneurs Docker » (2020), qui insiste sur le cloisonnement, le durcissement de l'hôte et la limitation des privilèges.

Exercices

services:
  front:
    image: ghcr.io/sorbier/sorbier-frais-front:2.4.0

services:
  front:
    image: ghcr.io/sorbier/sorbier-frais-front:2.4.0
    user: "101:101"
    read_only: true
    tmpfs:
      - /tmp
      - /var/cache/nginx
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    pids_limit: 100
    deploy:
      resources:
        limits:
          memory: 256M