115 lines
3 KiB
Markdown
115 lines
3 KiB
Markdown
\newpage
|
|
|
|
Garder des secrets
|
|
==================
|
|
|
|
Lorsque nous déployons des applications conteneurisées, celles-ci ont souvent
|
|
besoin d'informations sensibles : mots de passe de base de données, clefs API,
|
|
certificats, tokens d'authentification, etc. La gestion de ces secrets est
|
|
cruciale pour la sécurité de nos applications.
|
|
|
|
|
|
## Ce qu'il ne faut pas faire
|
|
|
|
Avant de voir les bonnes pratiques, commençons par les erreurs courantes à
|
|
éviter absolument :
|
|
|
|
::::: {.warning}
|
|
|
|
**Ne jamais inclure de secrets dans une image Docker !**
|
|
|
|
Lorsque vous construisez une image avec un `Dockerfile`, tout ce qui est copié
|
|
dans l'image y reste, même si vous le supprimez dans une couche ultérieure. Les
|
|
images peuvent être inspectées, et les secrets peuvent être extraits de
|
|
l'historique des couches.
|
|
|
|
:::::
|
|
|
|
::::: {.warning}
|
|
|
|
**Ne jamais passer de secrets via la ligne de commande !**
|
|
|
|
Les arguments de la ligne de commande sont visibles via `ps`, `docker inspect`,
|
|
et sont souvent enregistrés dans l'historique du shell.
|
|
|
|
<div lang="en-US">
|
|
```bash
|
|
# MAUVAIS EXEMPLE - À NE PAS FAIRE
|
|
docker container run -e DB_PASSWORD=monmotdepasse myapp
|
|
```
|
|
</div>
|
|
|
|
:::::
|
|
|
|
|
|
## Variables d'environnement avec fichiers
|
|
|
|
Pour éviter que les secrets n'apparaissent dans l'historique de commandes ou
|
|
dans les processus, Docker permet de charger les variables d'environnement
|
|
depuis un fichier :
|
|
|
|
<div lang="en-US">
|
|
```bash
|
|
docker container run --env-file secrets.env myapp
|
|
```
|
|
</div>
|
|
|
|
Le fichier `secrets.env` contiendrait :
|
|
|
|
<div lang="en-US">
|
|
```
|
|
DB_PASSWORD=monmotdepasse
|
|
API_KEY=ma_clef_secrete
|
|
```
|
|
</div>
|
|
|
|
::::: {.warning}
|
|
|
|
Pensez à ajouter ce fichier dans votre `.gitignore` ou `.dockerignore` pour éviter qu'il se retrouve accidentellement dans la nature !
|
|
|
|
:::::
|
|
|
|
|
|
## Montage de fichiers secrets
|
|
|
|
Une approche plus sécurisée consiste à monter les secrets comme fichiers en
|
|
lecture seule dans le conteneur :
|
|
|
|
<div lang="en-US">
|
|
```bash
|
|
docker container run \
|
|
--mount type=bind,source=$HOME/.secrets/db_password,target=/run/secrets/db_password,readonly \
|
|
myapp
|
|
```
|
|
</div>
|
|
|
|
L'application peut ensuite lire le secret depuis `/run/secrets/db_password`.
|
|
Cette approche présente plusieurs avantages :
|
|
|
|
- Les secrets ne sont pas visibles via `docker inspect`
|
|
- Les secrets peuvent avoir des permissions restrictives sur l'hôte
|
|
- Les applications peuvent être conçues pour lire les secrets depuis des
|
|
fichiers, ce qui est compatible avec les systèmes d'orchestration
|
|
|
|
|
|
## Docker Secrets (Docker Swarm)
|
|
|
|
Docker propose un système de gestion de secrets natif, mais celui-ci n'est
|
|
disponible qu'en mode Swarm.
|
|
|
|
<div lang="en-US">
|
|
```bash
|
|
# Création d'un secret (nécessite Swarm mode)
|
|
echo "monmotdepasse" | docker secret create db_password -
|
|
|
|
# Utilisation dans un service
|
|
docker service create --secret db_password myapp
|
|
```
|
|
</div>
|
|
|
|
Dans ce mode, les secrets sont :
|
|
|
|
- Chiffrés pendant le transit et au repos
|
|
- Montés dans `/run/secrets/` sous forme de fichiers temporaires en RAM
|
|
- Distribués uniquement aux conteneurs qui en ont besoin
|
|
- Gérés de manière centralisée
|