Bonjour ! Dans la leçon précédente, nous avons orchestré notre application Spring Boot et ses dépendances (MySQL, Redis) avec Docker Compose. C'était une étape majeure, mais nous avons terminé sur un point critique : les mots de passe et autres informations de configuration étaient écrits en clair dans notre fichier docker-compose.yml.
# Extrait de la leçon précédente - MAUVAISE PRATIQUE
services:
backend-app:
# ...
environment:
- SPRING_DATASOURCE_URL=jdbc:mysql://mysql-db:3306/appdb
- SPRING_DATASOURCE_USERNAME=user
- SPRING_DATASOURCE_PASSWORD=password # <- Secret en clair !
Cette approche est inacceptable dans un contexte professionnel. Elle expose des informations sensibles dans votre code source, rend difficile la gestion de différents environnements (développement, production) et va à l'encontre des bonnes pratiques fondamentales du développement logiciel, notamment le principe de The Twelve-Factor App qui stipule que la configuration doit être séparée du code.
L'objectif de cette leçon est donc de corriger cela. Vous allez apprendre à gérer les secrets et les variables d'environnement de manière sécurisée dans un contexte conteneurisé. Nous aborderons les stratégies allant du plus simple et immédiat (.env files) aux standards de l'industrie (vaults).
1. La solution immédiate : externaliser la configuration avec un fichier .env
La première étape pour sortir les informations sensibles de votre docker-compose.yml est d'utiliser un fichier .env. C'est un simple fichier texte, généralement placé à la racine de votre projet, qui contient des paires clé-valeur.
Le principe est simple :
- Vous créez un fichier nommé
.env. - Vous y placez vos variables de configuration et vos secrets.
- Vous ajoutez ce fichier à votre
.gitignorepour ne jamais le versionner ! - Docker Compose lira automatiquement ce fichier et rendra les variables disponibles.
Appliquons cela à notre exemple.
1. Créez un fichier .env à la racine du projet :
# .env file
# NE PAS COMMIT CE FICHIER
# MySQL Credentials
MYSQL_DATABASE=appdb
MYSQL_USER=user
MYSQL_PASSWORD=strongpassword123
MYSQL_ROOT_PASSWORD=rootpassword456
# Redis Config
REDIS_HOST=redis
REDIS_PORT=6379
2. Mettez à jour votre docker-compose.yml pour utiliser ces variables :
Notez la syntaxe ${VARIABLE_NAME}. Docker Compose substituera ces placeholders par les valeurs trouvées dans le fichier .env.
# docker-compose.yml (version améliorée)
version: '3.8'
services:
backend-app:
build: .
ports:
- "8080:8080"
environment:
- SPRING_PROFILES_ACTIVE=docker
- SPRING_DATASOURCE_URL=jdbc:mysql://${MYSQL_HOST:mysql-db}:${MYSQL_PORT:3306}/${MYSQL_DATABASE}
- SPRING_DATASOURCE_USERNAME=${MYSQL_USER}
- SPRING_DATASOURCE_PASSWORD=${MYSQL_PASSWORD}
- SPRING_DATA_REDIS_HOST=${REDIS_HOST}
- SPRING_DATA_REDIS_PORT=${REDIS_PORT}
# ... depends_on, networks ...
mysql-db:
image: mysql:8.0
environment:
- MYSQL_DATABASE=${MYSQL_DATABASE}
- MYSQL_USER=${MYSQL_USER}
- MYSQL_PASSWORD=${MYSQL_PASSWORD}
- MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD}
# ... ports, volumes, healthcheck, networks ...
# ... service redis ...
Remarquez la syntaxe ${MYSQL_HOST:mysql-db}. C'est une bonne pratique qui fournit une valeur par défaut (mysql-db dans ce cas) si la variable MYSQL_HOST n'est pas définie.
2. Maîtriser la gestion des variables avec Docker Compose
L'utilisation des variables d'environnement dans Docker Compose est un sujet riche. La vidéo suivante explore plusieurs aspects avancés qui vous seront très utiles.
Docker 🚀 Optimisez vos déploiements de conteneurs avec les variables d'environnement
La vidéo "Docker 🚀 Optimisez vos déploiements..." de GuiPoM - G. testé ! est une excellente ressource en français qui détaille en profondeur la gestion des variables d'environnement.
Regardez les sections suivantes dans cet ordre : Syntaxe des fichiers .env et interpolation (14:56 - 17:22) : Portez attention aux syntaxes pour les valeurs par défaut (${VAR:-default}) ou pour rendre une variable obligatoire (${VAR:?error message}). Ordre de précédence (12:52 - 14:56) : Comprenez dans quel ordre Docker Compose charge les variables (variables du shell, fichier .env, section environment: du compose.yml, etc.). C'est crucial pour le débogage. Utilisation de env_file (19:33 - 22:05) : Découvrez comment spécifier explicitement un ou plusieurs fichiers de variables, ce qui permet d'organiser la configuration par thématique (ex: db.env, app.env).
Cette méthode avec les fichiers .env est le standard pour le développement local. Elle est simple, efficace et garde vos secrets hors de Git. Mais est-ce vraiment sécurisé ?
3. Variables d'environnement vs. Secrets
Il est fondamental de comprendre qu'une variable d'environnement n'est pas un "secret" au sens cryptographique. Elle est simplement externalisée. Toute personne ayant accès à la machine et aux conteneurs peut potentiellement les lire.
Docker 🚀 Optimisez vos déploiements de conteneurs avec les variables d'environnement
Retournons à la vidéo de GuiPoM - G. testé ! pour bien comprendre cette distinction cruciale.
Regardez le segment de 09:35 à 12:52. L'auteur explique très clairement que les variables d'environnement ne cachent pas les données et peuvent être inspectées avec docker inspect. Il introduit le concept de Docker Secrets comme une alternative plus sécurisée.
Comme vous l'avez vu, Docker Secrets est un mécanisme natif de Docker (principalement pour le mode Swarm) où les secrets sont montés en tant que fichiers dans un tmpfs en mémoire dans le conteneur (dans /run/secrets/). L'application doit alors lire ces fichiers pour obtenir les secrets.
Bien que nous n'implémentions pas Docker Secrets directement avec Docker Compose pour le développement, le concept est essentiel : les vrais secrets méritent un traitement plus sécurisé qu'une simple variable d'environnement.
4. Stratégies de gestion des secrets en production
Pour des environnements de production ou des pipelines de CI/CD, l'utilisation de fichiers .env n'est pas suffisante. Il faut se tourner vers des solutions dédiées.
Securely Managing Secrets in CI/CD Pipelines - GOLOGIC
L'article "Securely Managing Secrets in CI/CD Pipelines" de Gologic offre un panorama des approches professionnelles. Il est en anglais, ce qui correspond à votre objectif de viser le marché international.
Lisez les sections suivantes pour comprendre la hiérarchie des solutions : "Golden rules" : Assimilez les 3 règles d'or de la gestion des secrets (moindre privilège, cycle de vie court, non-partage). "Level 2: Secret Vault" : C'est le standard de l'industrie. Comprenez ce qu'est un coffre-fort à secrets (Vault) et les différentes catégories : CI Provider Vaults (ex: GitHub Secrets), Cloud Provider Vaults (ex: AWS Secrets Manager), et solutions dédiées (ex: HashiCorp Vault). "Level 3: Short-lived Credentials and Auths Protocols" : Prenez connaissance de l'approche la plus moderne, qui vise à éliminer les secrets à longue durée de vie en utilisant des jetons temporaires (via OIDC).
La solution la plus courante et la plus robuste aujourd'hui est l'utilisation d'un Secret Vault.
Les diapositives suivantes résument bien les bonnes et mauvaises pratiques dans l'écosystème Spring Boot / Conteneurs.
Spring Boot & Containers - Do's & Don'ts slides
Ces diapositives (resource_id: LINK) rappellent des points essentiels : "jamais de secrets dans les properties !" (section 0), "jamais de secrets dans un Dockerfile" (section 2) et soulignent que même les "Secrets Kubernetes" ne sont pas si secrets, recommandant des solutions comme Vault (section 4).
5. Intégration moderne avec Spring Boot 3.1+
Pour boucler la boucle, il est intéressant de noter que Spring Boot lui-même évolue pour simplifier ce workflow en développement. Depuis la version 3.1, une nouvelle dépendance docker-compose-support facilite encore plus l'intégration.
Le professeur Mohamed YOUSSFI présente cette nouvelle fonctionnalité dans sa vidéo "Spring Docker compose support".
Regardez les segments 00:00:08 - 02:15, 03:37 - 06:57, et 13:29 - 17:16. L'essentiel à retenir est qu'en ajoutant cette dépendance, Spring Boot va : Démarrer automatiquement les services définis dans docker-compose.yml quand vous lancez votre application depuis votre IDE. Lire les variables d'environnement (MYSQL_DATABASE, MYSQL_USER, etc.) directement depuis le docker-compose.yml pour configurer la connexion, sans même avoir besoin de les définir dans application.properties.
Cette fonctionnalité montre à quel point l'intégration entre le framework et les outils de conteneurisation devient profonde, simplifiant l'expérience de développement tout en s'appuyant sur les mêmes principes d'externalisation de la configuration.
Conclusion
Vous avez maintenant une vision claire et structurée de la gestion des configurations et des secrets, une compétence non-négociable pour tout développeur professionnel.
Points clés à retenir :
- Ne jamais versionner les secrets. La configuration doit toujours être séparée du code.
- Pour le développement local, la méthode standard consiste à utiliser un fichier
.env(ajouté au.gitignore) avec des variables substituées dansdocker-compose.yml. - Les variables d'environnement sont visibles et ne doivent pas être considérées comme un mécanisme de sécurité robuste. Elles servent à externaliser la configuration.
- Pour la production, l'utilisation d'un Secret Vault (HashiCorp Vault, AWS/Azure/GCP Secret Manager, GitHub Secrets pour la CI/CD) est la norme. L'application récupère les secrets dynamiquement auprès du vault.
Dans la leçon précédente, nous avons configuré notre stack. Aujourd'hui, nous l'avons sécurisée et rendue configurable. Nous sommes maintenant prêts à automatiser le processus.
Prochaine étape :
Dans la prochaine leçon, nous allons mettre en place un pipeline de CI/CD avec GitHub Actions. Nous y appliquerons directement ce que nous venons d'apprendre en utilisant les GitHub Secrets (un "CI Provider Vault") pour fournir les informations d'identification nécessaires à la construction et au test de notre application de manière automatisée et sécurisée.