Sécurité Docker : les bases pour durcir les conteneurs en 2026

# Installation rootless Docker (utilisateur sans root)
curl -fsSL https://get.docker.com/rootless | sh
 
# Variables d'environnement à ajouter au shell
export PATH=$HOME/bin:$PATH
export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock
 
# Vérifier le mode
docker info | grep -i rootless

// /etc/docker/daemon.json
{
  "userns-remap": "default",
  "live-restore": true,
  "no-new-privileges": true,
  "icc": false,
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "3" }
}

OS de l'hôte :
  Mise à jour continue (unattended-upgrades Debian, dnf-automatic RHEL)
  Désactiver services inutiles
  Firewall restrictif (ufw, nftables, iptables)
  SSH : pas de password, key-only, port non-standard si exposé
 
Kernel :
  AppArmor (Ubuntu, Debian) ou SELinux (RHEL, Fedora) actif
  Filesystem /var/lib/docker sur volume chiffré (LUKS)
  Module kernel : désactiver ceux non utilisés

ubuntu:24.04                         : 77 MB, 90+ CVE résiduelles
python:3.12-slim                     : 45 MB, 20-40 CVE
python:3.12-alpine                   : 19 MB, 15-30 CVE
gcr.io/distroless/python3            : 25 MB, 0-5 CVE
cgr.dev/chainguard/python            : 15 MB, 0-3 CVE (sponsored)
scratch + binaire Go statique        : 5-15 MB, 0 CVE distro

# Pinning par digest SHA256 immuable (pas juste par tag)
docker pull python:3.12.6-slim@sha256:1a89c1d4...
 
# Vérification signature cosign keyless
cosign verify \
  --certificate-identity-regexp "https://github.com/org/.*" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ghcr.io/org/app:sha-abc123

# Stage 1 - build (gros, outils inclus)
FROM golang:1.22.3-alpine@sha256:d3d5b... AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /bin/app ./cmd/app
 
# Stage 2 - runtime (minimal, no shell, non-root)
FROM gcr.io/distroless/static-debian12:nonroot
USER 65532:65532
WORKDIR /app
COPY --from=build --chown=65532:65532 /bin/app /app/app
 
EXPOSE 8080
ENTRYPOINT ["/app/app"]

# syntax=docker/dockerfile:1.6
 
FROM alpine:3.19
RUN --mount=type=secret,id=github_token \
    TOKEN=$(cat /run/secrets/github_token) && \
    curl -H "Authorization: token $TOKEN" https://api.github.com/... -o /data.json

# Build avec secret injecté (non persisté dans layer)
DOCKER_BUILDKIT=1 docker build \
  --secret id=github_token,src=/path/to/token \
  -t my-app .

docker run \
  --read-only \                          # rootfs en lecture seule
  --tmpfs /tmp:rw,size=64M,noexec \      # /tmp isolé
  --user 10001:10001 \                   # non-root
  --cap-drop=ALL \                       # drop toutes les capabilities
  --cap-add=NET_BIND_SERVICE \           # réajouter ce qui est strictement nécessaire
  --security-opt=no-new-privileges \     # pas d'escalade via setuid
  --security-opt=seccomp=profile.json \  # profile seccomp custom
  --security-opt=apparmor=app-profile \  # profile AppArmor
  --pids-limit=100 \                     # limite PID pour éviter fork bomb
  --memory=512m --memory-swap=512m \     # limite RAM
  --cpus=1.0 \                           # limite CPU
  --network=my-app-net \                 # pas le bridge default
  my-app:1.2.3@sha256:abc...

Capabilities dangereuses à DROP absolument :
  CAP_SYS_ADMIN         : « root-lite », très puissant
  CAP_SYS_MODULE        : chargement modules kernel
  CAP_SYS_PTRACE        : debug et injection processus
  CAP_SYS_RAWIO         : accès matériel brut
  CAP_NET_ADMIN         : configuration réseau
  CAP_SYS_BOOT          : reboot
  CAP_DAC_READ_SEARCH   : lecture contournant les permissions
  CAP_SETUID / SETGID   : changement d'UID/GID
 
Capabilities souvent nécessaires à ajouter :
  CAP_NET_BIND_SERVICE  : écouter sur port inférieur à 1024
  CAP_CHOWN             : chown dans le conteneur
  CAP_SETGID / SETUID   : si l'app change d'UID explicitement

# Voir le profil seccomp par défaut
docker run --rm alpine cat /proc/1/status | grep Seccomp
 
# Profil custom : autoriser uniquement les syscalls nécessaires
docker run --security-opt=seccomp=/path/to/my-profile.json my-app

# AppArmor - appliquer un profile custom
docker run --security-opt=apparmor=my-app-profile my-app
 
# Voir le profile par défaut Docker
cat /etc/apparmor.d/docker-default

docker run --read-only --tmpfs /tmp:rw,size=64M my-app

# Créer un réseau dédié
docker network create --driver=bridge my-app-net
 
# Lancer les conteneurs dans ce réseau
docker run --network=my-app-net --name=api my-api:1.0
docker run --network=my-app-net --name=db my-db:1.0

# Mauvais - publication sur toutes les interfaces
docker run -p 5432:5432 postgres  # écoute 0.0.0.0:5432, exposé Internet
 
# Meilleur - binding localhost seulement
docker run -p 127.0.0.1:5432:5432 postgres
 
# Encore mieux - pas de publication, accès via réseau user-defined
docker run --network=my-app-net --name=db postgres

Ne JAMAIS :
  Monter /var/run/docker.sock dans un conteneur exposé (Traefik, Portainer
  exposés Internet) - équivaut à root sur l'hôte pour l'attaquant.
 
Alternatives :
  Podman socket rootless
  Docker Socket Proxy (Tecnativa) pour exposer une API restreinte
  Traefik avec socket read-only + mode file plutôt que dynamic

À éviter :
  Secret dans le Dockerfile (ARG ou ENV)     → fuit via docker history
  Secret dans docker run -e SECRET=...        → fuit via docker inspect + logs
  Secret en clair dans un volume monté        → fuit si volume exposé
 
Acceptable pour dev local :
  Fichier .env chargé via docker run --env-file
  Secret dans Docker Desktop Secrets
 
Recommandé pour production :
  Docker Secrets (Swarm uniquement)
  Kubernetes Secrets (avec encryption at rest etcd + Sealed Secrets)
  HashiCorp Vault (sidecar injector ou Vault Agent)
  Cloud-native : AWS Secrets Manager, GCP Secret Manager, Azure Key Vault
  OIDC Workload Identity Federation pour CI/CD (sans secret du tout)

# Générer un Sealed Secret chiffré avec la clé publique du cluster
echo -n "my-super-secret-value" | kubectl create secret generic my-secret \
  --dry-run=client --from-file=db-password=/dev/stdin -o yaml | \
  kubeseal --format yaml > sealed-secret.yaml
 
# Le fichier sealed-secret.yaml est commitable dans Git, chiffré.
# Le cluster a la clé privée pour le déchiffrer.

1. Host Configuration              (~20 contrôles)
2. Docker Daemon Configuration     (~35 contrôles)
3. Docker Daemon Files             (~15 contrôles)
4. Container Images and Build File (~12 contrôles)
5. Container Runtime               (~30 contrôles)
6. Docker Security Operations      (~2 contrôles)
7. Docker Swarm Configuration       (~9 contrôles)

# Docker Bench Security (script officiel, 117 checks)
docker run --rm --net host --pid host --userns host --cap-add audit_control \
  -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
  -v /etc:/etc:ro \
  -v /usr/bin/containerd:/usr/bin/containerd:ro \
  -v /usr/bin/runc:/usr/bin/runc:ro \
  -v /usr/lib/systemd:/usr/lib/systemd:ro \
  -v /var/lib:/var/lib:ro \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  --label docker_bench_security \
  docker/docker-bench-security
 
# Alternative : Trivy compliance CIS
trivy image --compliance docker-cis my-app:1.0
 
# Alternative : Prowler multi-cloud
prowler -c cis_docker

Image et build :
  [ ] Image de base minimale (distroless, Chainguard ou Alpine pinné)
  [ ] FROM avec digest SHA256 immuable
  [ ] Multi-stage build avec runtime stripped
  [ ] USER non-root explicite dans Dockerfile
  [ ] .dockerignore complet (.git, .env, node_modules, tests)
  [ ] Pas de secret dans ARG ou ENV
  [ ] HEALTHCHECK défini
 
Runtime :
  [ ] --cap-drop=ALL + --cap-add explicites
  [ ] --security-opt=no-new-privileges
  [ ] --read-only + --tmpfs /tmp
  [ ] --pids-limit, --memory, --cpus définis
  [ ] Seccomp custom pour applications à fort volume d'utilisateurs
  [ ] AppArmor ou SELinux profile dédié
 
Hôte :
  [ ] Rootless Docker ou user namespaces activé
  [ ] daemon.json hardened (no-new-privileges, live-restore, icc:false)
  [ ] Docker Bench Security > 80 % pass
  [ ] OS hardened (AppArmor/SELinux, firewall)
 
Secrets :
  [ ] Aucun secret dans l'image
  [ ] Docker Secrets, Vault ou Cloud secret service utilisé
  [ ] BuildKit secrets pour les builds nécessitant credentials
 
Réseau :
  [ ] Pas de bridge default, réseaux user-defined
  [ ] Pas de docker.sock monté dans un conteneur exposé
  [ ] Binding 127.0.0.1 pour services non publics
  [ ] TLS sur l'API Docker si exposée (rare, déconseillé)
 
Observabilité :
  [ ] Logs conteneurs remontés dans un SIEM
  [ ] Détection runtime (Falco, Tetragon) si criticité élevée