Docker facilite la conteneurisation des applications, mais les paramètres par défaut sont loin d'être sécurisés. Les conteneurs exécutés en tant que root, les images gonflées avec des packages inutiles et les limites de ressources manquantes posent des risques sérieux. Dans ce tutoriel pratique, nous parcourons chaque étape pour rendre vos conteneurs Docker prêts pour la production et sécurisés.
Images de base minimales et builds multi-étapes
La première règle de la sécurité des conteneurs : minimiser la surface d'attaque. Utilisez Alpine Linux (5 Mo) ou des images distroless au lieu d'images Ubuntu ou Debian complètes. Chaque package supplémentaire dans votre image est une vulnérabilité potentielle. Avec les builds multi-étapes, vous compilez votre application dans une étape builder avec tous les outils de développement, et copiez uniquement l'artefact final vers une image runtime minimale.
Scannez régulièrement vos images avec des outils comme Trivy, Snyk ou Docker Scout. Intégrez cela dans votre pipeline CI/CD pour que les images vulnérables n'atteignent jamais la production. Épinglez vos versions d'images de base avec un hash digest spécifique au lieu de tags mutables comme :latest pour prévenir les risques de supply chain.
# Dockerfile optimal avec build multi-étapes
# Étape 1 : Build
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build
# Étape 2 : Runtime (image minimale)
FROM gcr.io/distroless/nodejs20-debian12
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
# Exécuter en tant qu'utilisateur non-root (uid 1000)
USER 1000
EXPOSE 3000
CMD ["dist/server.js"]Utilisateurs non-root, systèmes de fichiers en lecture seule et limites de ressources
Les conteneurs s'exécutent en tant que root par défaut — un risque de sécurité énorme. Si un attaquant s'échappe du conteneur, il a un accès root sur l'hôte. Utilisez toujours la directive USER dans votre Dockerfile pour exécuter en tant qu'utilisateur non-root. Créez un utilisateur dédié ou utilisez l'utilisateur intégré node, www-data ou nobody.
Exécutez les conteneurs avec un système de fichiers root en lecture seule via --read-only. Ne montez que des répertoires spécifiques en écriture là où votre application doit écrire des fichiers temporaires. Définissez aussi toujours des limites de ressources avec --memory et --cpus pour empêcher un conteneur compromis d'épuiser l'ensemble du système. Supprimez toutes les capabilities Linux avec --cap-drop ALL et ne rajoutez que celles strictement nécessaires.
- Utilisez distroless ou Alpine comme image de base — évitez les images gonflées
- Exécutez toujours en non-root avec la directive USER
- Activez le système de fichiers root en lecture seule avec le flag --read-only
- Définissez des limites de mémoire et CPU pour chaque conteneur
- Supprimez toutes les capabilities avec --cap-drop ALL et n'ajoutez que les nécessaires
- Scannez les images avec Trivy ou Snyk dans votre pipeline CI/CD
Sécurité runtime et secrets dans Docker
La sécurité au moment du build n'est que la moitié de l'histoire. Utilisez le profil seccomp de Docker pour restreindre les syscalls et AppArmor ou SELinux pour le contrôle d'accès obligatoire. Activez également --no-new-privileges pour empêcher les processus du conteneur d'escalader leurs privilèges après le démarrage.
Ne stockez jamais de secrets dans les images Docker ou les variables d'environnement. Utilisez Docker Secrets (dans Swarm) ou des gestionnaires de secrets externes comme HashiCorp Vault. Pour le développement, vous pouvez utiliser Docker Compose avec un fichier .env dans .gitignore. En production, montez les secrets comme des fichiers dans un volume tmpfs avec des permissions restrictives (0400). N'oubliez pas de sécuriser votre daemon Docker lui-même : activez TLS, restreignez l'accès API et maintenez Docker à jour.
Conseil Pro
Exécutez docker run --rm -v /var/run/docker.sock:/var/run/docker.sock aquasec/trivy image <votre-image> sur vos images de production maintenant. Vous trouverez probablement des vulnérabilités critiques dans vos images de base. Passez ensuite à une image de base distroless ou Alpine, ajoutez USER 1000 à chaque Dockerfile, et vous aurez éliminé 80% des vulnérabilités de conteneurs les plus courantes en moins d'une heure.
Partager cet article