Docker, c’est un peu le “pain au chocolat” de la tech : tout le monde adore, tout le monde en parle, mais dès qu’il s’agit de sécurité, bizarrement, il n’y a plus grand monde à la machine à café. À force de répéter que “c’est isolé, c’est flexible, c’est portable”, on finit par croire que c’est invulnérable. Pourtant, une config un peu trop permissive, un mauvais montage de volume, et hop, c’est open bar dans la prod.
On en rigole… jusqu’au jour où la prod rigole moins.
Parce que derrière les belles promesses, la sécurité Docker “sortie d’usine”, c’est souvent plus fragile qu’on ne veut bien l’admettre. Voici le décryptage, sans filtre, pour tous ceux qui préfèrent prévenir que devoir expliquer à 8h pourquoi tout est down.
Docker, c’est pratique, mais niveau sécurité… faut pas pousser
Petit rappel pour ceux du fond : Docker, c’est génial pour emballer ton appli, la balancer sur un serveur/VM/cloud/raspberry/Toaster connecté, et tout marche pareil. Côté sécurité, par contre, on est loin du mythe du conteneur indestructible : Le démon Docker tourne souvent en root (ouch)
Tout repose sur les protections du noyau Linux (donc “ça va”, jusqu’au jour où…). Les conteneurs peuvent parfois plus papoter entre eux qu’on le pense. Bref, c’est pas la zone verte.
Docker version 7 commandements
1. Cloisonner tu devras
Pas de conteneur en mode –privileged : Si tu fais ça, autant donner les clés de ta maison au premier passant.
Pas de montage sauvage :Tu ne partages ni /, ni /dev, ni /proc, ni /sys à moins d’avoir une (très) bonne raison. Et si tu montes un volume, tu privilégies le read-only, comme ton ex avec ton compte Netflix.
2. Avec le réseau, n’importe quoi tu ne feras pas
Exit le bridge Docker0 pour tout le monde : Le réseau “par défaut” ? C’est le hall d’immeuble où tout le monde s’espionne.
Pas de –network host :Non, ce n’est pas “plus simple”, c’est juste dangereux.
Un réseau dédié pour chaque service sensible : Web et base de données ? On sépare les flux, comme dans une vraie cuisine.
3. Les namespaces tu sépareras
PID, IPC, UTS : chacun son espace, chacun sa vie.
USERNS : c’est bien, mais pas parfait. Active –userns-remap, ça t’évitera que le “root” du conteneur soit aussi le “root” de l’hôte (sinon, c’est open-bar en cas de faille).
4. Le moindre privilège tu appliqueras
On lance tout avec le moins de privileges possible : –cap-drop=ALL + tu réactives les droits au cas par cas (–cap-add) si et seulement si tu sais pourquoi.
Évite de lancer tes applis en root : Crée-toi un user dans ton Dockerfile, c’est pas compliqué et ça évite les mauvaises surprises.
5. Avare avec les ressources tu seras
Limite la mémoire et le CPU(–memory, –memory-swap, –cpus, etc.) : un conteneur qui part en vrille ne doit pas emmener le serveur avec lui.
File system en lecture seule (–read-only). Les changements ? Tu les mets dans un volume dédié, point.
6. Le stockage a trier tu penseras
Tmpfs pour le temporaire (ramdisk, limité, effacé à l’arrêt du conteneur)
Bind-mount ou volume dédié pour les données persistantes, en lecture seule si possible
Pas de partage de fichiers sensibles : on n’est pas chez les Bisounours
7. Dans un autre lieu tu loggeras
Centralise tes logs (avec –log-driver) sur un serveur externe. Car un conteneur qui tombe, c’est aussi tes logs qui disparaissent si tu n’as rien prévu.
La morale ?
Quand on vous vend Docker comme la solution à tous les problèmes d’isolation… Méfiez-vous !
Comme toujours, la sécurité, c’est pas la couche qu’on rajoute à la fin, c’est ce qu’on doit penser dès le départ.
Et si malgré tout, ça tombe…
Au moins, vous saurez que vous aviez fait le max, et que la prochaine fois, c’est peut-être chez le voisin que ça plantera en premier.
Et si vous voulez aller plus loin, voici comment déployer facilement un Magento avec Docker et Warden.
