Sécurité Maximale
Blinder vos livrables pour la Production
Un conteneur Docker n'est pas une machine virtuelle. Il partage le Noyau (Kernel) de la machine hôte. Si un Hacker parvient à exploiter une faille dans votre API Node.js, et que cette API tourne en mode Administrateur suprême (Root) dans le conteneur... Le Hacker pourrait "s'échapper" du conteneur et prendre le contrôle total du serveur.
Règle #1 : Ne jamais tourner en Root
Défaut (Utilisateur Root)
L'API Node.js tourne avec les droits d'administration. Une faille RCE (Remote Code Execution) permet de détruire le système.
Sécurisé (Utilisateur App)
L'API tourne en tant qu'utilisateur "node" bridé, qui n'a le droit de lire que son propre dossier /app.
Par défaut, toutes les images officielles (Ubuntu, Node, Python) exécutent leurs processus en `root`. C'est à VOUS de rétrograder cet accès dans le `Dockerfile`.
FROM node:20-alpine
# Alpine n'a pas bash, mais permet la création d'utilisateur
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
WORKDIR /app
# On copie les fichiers en donnant la propriété (chown) au nouvel utilisateur
COPY --chown=appuser:appgroup package.json .
RUN npm install
COPY --chown=appuser:appgroup . .
# CRITIQUE : On change d'identité (On quitte Root) AVANT de lancer l'application
USER appuser
EXPOSE 3000
CMD ["npm", "start"]Règle #2 : La Faille des Secrets Inclus
COPY .env . dans le Dockerfile.
Rappelez-vous le fonctionnement par "Couches" (Layers). Tout ce qui est écrit dans un Layer y reste pour l'éternité. Si vous copiez un fichier `.env` contenant vos mots de passe DB pendant la construction, n'importe qui téléchargeant l'image pourra extraire ce fichier via `docker history`, même si vous le supprimez dans un `RUN rm .env` ultérieur !
Solution : Ne copiez JAMAIS d'identifiants dans l'image. Injectez-les uniquement au moment du `docker run` (via --env-file) ou dans `docker-compose.yml` (via env_file).
Audit et Nettoyage de l'Hôte
Docker fournit des outils incroyables pour vérifier vos failles connues (CVE) et pour purger les disques durs saturés par les vieux conteneurs.
# 1. Scanner une image contre les bases de données de CVE (vulnérabilités connues)
docker scout cves mon-image:latest
# 2. Voir ce qui dévore votre Disque Dur (Images, Volumes ?)
docker system df
# 3. Le "Coup de Balai Magique" : Supprime tout ce qui n'est pas utilisé actuellement.
# (Conteneurs stoppés, Réseaux morts, Images orphelines sans tag)
docker system prune
# 4. Le "Lance-flammes" : Détruit même les images de base si elles ne servent plus
docker system prune -a --volumesRègle #3 : Filesystem en Lecture Seule
Si votre application n'a pas besoin d'écrire sur son propre filesystem (ce qui est souvent le cas d'une API ou d'un serveur statique), forcez le conteneur en mode lecture seule. Ainsi, même si un attaquant parvient à exécuter du code dans votre conteneur, il ne peut pas installer de malware, créer de scripts malveillants, ni modifier les binaires.
# flag --read-only + une exception en RAM pour /tmp si besoin
docker run --read-only --tmpfs /tmp mon-apiservices:
api:
image: mon-api
read_only: true # Filesystem racine gelé
tmpfs:
- /tmp # Exception : RAM pour les fichiers temporairesValidez ces points essentiels avant chaque déploiement. Cochez chaque règle appliquée :