Dockerfile Best Practices Security

Définition

Les Dockerfile Best Practices de sécurité sont un ensemble de bonnes pratiques de rédaction des Dockerfiles pour créer des images conteneurs sûres, minimisant la surface d'attaque et les vulnérabilités dans les images résultantes. Ces pratiques couvrent le choix des images de base, la gestion des utilisateurs, la gestion des secrets pendant le build, et la réduction de la taille et du contenu des images finales. La première pratique critique est d'utiliser des images de base officielles et minimales. Préférez les variantes slim ou alpine des images officielles (python:3.12-slim plutôt que python:3.12 complète) qui n'incluent pas les outils de build, les compilers, et les packages non nécessaires à l'exécution. Les images distroless de Google (gcr.io/distroless/python3) sont encore plus minimalistes : elles ne contiennent que l'application et ses dépendances runtime, sans shell ni gestionnaire de paquets. La gestion des utilisateurs est critique : les conteneurs ne doivent pas s'exécuter en tant que root. Créez un utilisateur non-privilegié dans le Dockerfile (RUN useradd -r -s /bin/false appuser) et basculez sur cet utilisateur avant la commande CMD/ENTRYPOINT (USER appuser). Vérifiez que les fichiers de l'application appartiennent à cet utilisateur et que les répertoires sensibles n'ont pas des permissions trop larges. La gestion des secrets dans les Dockerfiles est un risque majeur : ne jamais utiliser ARG ou ENV pour passer des secrets (ils apparaissent dans l'historique des layers Docker via docker history), ne jamais copier de fichiers de secrets (.env, credentials.json, .aws/credentials) dans l'image. Utilisez les BuildKit secrets (--mount=type=secret) pour accéder aux secrets pendant le build sans les inclure dans les layers de l'image. Le multi-stage build est une pratique fondamentale pour la sécurité : compilez l'application dans un stage "builder" incluant les outils de compilation (gcc, go, node avec devDependencies), puis copiez uniquement les artefacts binaires dans un stage final minimal. L'image finale ne contient pas les outils de build, réduisant la surface d'exploitabilité post-compromission.