Guide complet Docker Secrets : sécuriser mots de passe et clés API des conteneurs

Le téléphone vibre sans arrêt — 24 SMS, tous des alertes d’anomalie sur la base de données. Vous vous connectez en SSH : le nombre de connexions est saturé, quelqu’un lance un scan par force brute.

Les logs montrent que l’attaquant a utilisé le bon mot de passe — celui de MySQL écrit dans docker-compose.yml il y a trois mois. Le mois dernier, un stagiaire a forké le projet vers son dépôt public pour s’entraîner, et le mot de passe a fuité.

Même sans fuite de code, quiconque peut exécuter docker inspect voit toutes les variables d’environnement — en clair. Cet article parle de la gestion des mots de passe dans les conteneurs : quelles pratiques éviter, et quels outils protègent vraiment les informations sensibles.

Pourquoi les variables d’environnement ne sont pas sûres ?

Trois pratiques courantes et dangereuses

Commençons par les erreurs que j’ai moi-même commises — voyez si vous vous reconnaissez.

Première : écrire directement dans le Dockerfile

FROM node:18
ENV DATABASE_PASSWORD=MyS3cr3tP@ssw0rd
ENV API_KEY=sk-1234567890abcdef

C’est la pire option. Chaque instruction du Dockerfile crée une couche d’image ; même si vous écrasez ensuite avec ENV DATABASE_PASSWORD="", le mot de passe reste dans l’historique des couches. N’importe qui avec votre image peut l’extraire avec docker history <nom-image>.

Vous n’y croyez pas ? Moi non plus, jusqu’à ce qu’un collègue me le démontre. Il a tiré une image interne de notre entreprise et, en quelques commandes, a extrait une clé d’accès AWS laissée par un ancien collègue il y a trois ans — qu’on avait oublié de supprimer.

Deuxième : écrire dans docker-compose.yml

version: '3.8'
services:
  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: SuperSecretPassword123
      MYSQL_DATABASE: myapp

Je l’ai utilisé longtemps. Raison simple : pratique. Un docker-compose up -d et c’est lancé, développement et débogage efficaces.

Le problème ? Ce fichier va dans Git. Même privé, une mauvaise gestion des droits — ou, comme chez moi, un fork vers un dépôt public — et le mot de passe est exposé.

Troisième : fichier .env versionné

# fichier .env
DB_PASSWORD=password123
API_SECRET=abcdef123456

Ça paraît plus malin : extraire les secrets dans un .env séparé, puis référencer ${DB_PASSWORD} dans docker-compose.

Mais beaucoup (moi y compris) commitent aussi le .env dans Git, en se disant « l’équipe doit pouvoir lancer le projet ». Résultat identique à docker-compose en clair.

La bonne pratique : ajouter .env à .gitignore et fournir un modèle .env.example. Honnêtement, au début, qui y pense ?

Trois risques majeurs des variables d’environnement

Même avec .env dans .gitignore, même sans fuite de code, les variables d’environnement restent peu sûres. Pourquoi ?

Risque 1 : docker inspect expose tout

Essayez :

docker inspect <container-ID> | grep -A 20 "Env"

Toutes les variables d’environnement, mots de passe inclus, s’affichent en clair.

Conséquence : quiconque accède au démon Docker — ops, DevOps, développeurs avec accès serveur — voit vos mots de passe. Pas de crack, pas de technique avancée : une seule commande.

Dans une startup où j’étais, tout le monde avait l’accès SSH à la prod par commodité. Un nouveau développeur frontend, curieux de savoir « ce qu’il y a dans le conteneur », a lancé docker inspect — et le mot de passe de la base s’est affiché à l’écran. Heureusement, c’était un collègue de confiance.

Risque 2 : les processus dans le conteneur peuvent lire

Docker n’est pas le seul à voir les variables : tous les processus du conteneur aussi. Sous Linux, elles sont dans /proc/<PID>/environ.

Si une dépendance de votre application a une faille et qu’un attaquant injecte du code, il peut lire les variables d’environnement et récupérer le mot de passe.

L’an dernier, une bibliothèque Node.js a été compromise : elle lisait les identifiants AWS dans les variables d’environnement et les envoyait à l’extérieur. Des dizaines de milliers de projets touchés.

Risque 3 : fuite possible dans les logs

Plus discret encore.

Au démarrage, l’application imprime souvent la configuration ; en cas d’erreur, elle peut dumper les variables d’environnement dans les logs. Les fichiers de logs ont souvent des permissions laxistes, voire sont centralisés (ELK, etc.).

J’ai vu des équipes agréger tous les logs de conteneurs dans Elasticsearch ; lors d’un audit, des centaines de mots de passe de base de données traînaient dans les logs — des développeurs qui console.log(process.env) en débogage et oubliaient de retirer.

Pire : une fois le mot de passe dans les logs, difficile de l’effacer complètement — copies, archives, sauvegardes.

Cas réels

Ce genre d’incident est fréquent, même si peu d’entreprises le rendent public. Quelques exemples que je connais :

Cas 1 : fuite via dépôt GitHub public

En 2023, une analyse montrait que plus d’un million de dépôts publics sur GitHub contenaient des clés API, mots de passe de base de données, etc. Ce n’est pas de la maladresse — souvent un oubli : config de test non supprimée, ou .env commité par accident.

Un ami en machine learning : son équipe a open-sourcé du code d’entraînement sur GitHub avec les identifiants AWS. En 24 heures, quelqu’un a lancé des instances GPU pour miner. Facture : plus de 20 000 dollars.

Cas 2 : historique CI/CD

Les outils CI/CD (Jenkins, GitLab CI, etc.) conservent souvent les logs de build avec les variables d’environnement. Sans masquage, ces logs deviennent une bibliothèque de mots de passe.

Un projet avec GitLab CI : un collègue partant avait donné l’accès au dépôt à une équipe externe. Quelqu’un a fouillé l’historique des builds et récupéré les infos de connexion à la base de production. Heureusement, ils nous ont prévenus pour aider — et s’ils avaient eu de mauvaises intentions ?

Cas 3 : scan d’images Docker Hub

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

Un rapport de sécurité d’Alibaba : en scannant des images Docker publiques, 76 % présentaient des vulnérabilités, dont beaucoup avec des identifiants codés en dur.

Certaines entreprises poussent des images internes sur Docker Hub public en pensant « personne ne s’intéressera à notre petite boîte ». Des crawlers automatisés scannent en permanence. Votre image peut être analysée en quelques minutes.

Ce n’est pas pour effrayer — ces problèmes arrivent vraiment, plus souvent qu’on ne le croit. Et on peut les éviter.

Qu’est-ce que Docker Secrets ? Comment l’utiliser ?

Fonctionnement de Docker Secrets

Passons aux solutions.

Docker Secrets est le mécanisme officiel de gestion des clés. En bref : le secret n’est plus une chaîne en clair, mais un fichier chiffré.

Le flux :

1. Vous créez un secret ; Docker le chiffre et le stocke dans le journal Raft du cluster
2. Quand un conteneur en a besoin, Docker le transmet via une connexion TLS chiffrée
3. Le secret est monté comme fichier dans /run/secrets/ du conteneur
4. Ce répertoire est un tmpfs — système de fichiers en mémoire, rien n’est écrit sur disque
5. À l’arrêt du conteneur, le secret est effacé de la mémoire

Point clé : le secret n’apparaît pas dans les variables d’environnement, ni dans docker inspect, ni dans une image via docker commit.

Abstrait ? Normal — ma première lecture de la doc Docker aussi. Mieux vaut essayer directement.

Limitation : Docker Secrets natif ne fonctionne qu’en mode Swarm. Frustrant au début — développement local, machine unique, pourquoi pas ?

docker-compose supporte aussi les file secrets (moins puissant, mais utilisable). En production en cluster, Swarm ou Kubernetes conviennent.

Tutoriel pas à pas : MySQL + WordPress

Exemple complet : déployer un blog WordPress en protégeant le mot de passe root MySQL et le mot de passe utilisateur.

Étape 1 : créer les fichiers de secret

Écrire les mots de passe dans des fichiers locaux (ne pas les committer dans Git) :

echo "MyRootPassword123" > db_root_password.txt
echo "MyUserPassword456" > db_password.txt

Étape 2 : initialiser Swarm (si pas déjà fait)

docker swarm init

Une seule commande. Si Swarm n’est pas activé, lancez-la. Swarm fonctionne aussi sur une seule machine.

Étape 3 : créer les Docker secrets

docker secret create mysql_root_password db_root_password.txt
docker secret create mysql_password db_password.txt

Puis supprimer immédiatement les fichiers locaux :

rm db_root_password.txt db_password.txt

Important : une fois lus et chiffrés par Docker, les fichiers en clair local doivent disparaître.

Vérifier :

docker secret ls

Sortie typique :

ID                          NAME                  CREATED         UPDATED
abc123...                   mysql_root_password   5 seconds ago   5 seconds ago
def456...                   mysql_password        3 seconds ago   3 seconds ago

Vous ne voyez pas le contenu du secret — seulement le nom et les métadonnées. Même un administrateur ne récupère pas le texte en clair après création.

Étape 4 : créer docker-compose.yml

version: '3.8'

secrets:
  mysql_root_password:
    external: true
  mysql_password:
    external: true

services:
  db:
    image: mysql:8.0
    secrets:
      - mysql_root_password
      - mysql_password
    environment:
      MYSQL_ROOT_PASSWORD_FILE: /run/secrets/mysql_root_password
      MYSQL_PASSWORD_FILE: /run/secrets/mysql_password
      MYSQL_USER: wordpress
      MYSQL_DATABASE: wordpress
    volumes:
      - db_data:/var/lib/mysql

  wordpress:
    image: wordpress:latest
    depends_on:
      - db
    ports:
      - "8080:80"
    secrets:
      - mysql_password
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD_FILE: /run/secrets/mysql_password
      WORDPRESS_DB_NAME: wordpress

volumes:
  db_data:

Points clés :

1. secrets au niveau racine : déclare les secrets ; external: true = déjà créés, pas par compose
2. services.db.secrets : secrets utilisés par ce service
3. MYSQL_ROOT_PASSWORD_FILE : l’image MySQL officielle supporte le suffixe _FILE pour lire depuis un fichier

Le suffixe _FILE n’est pas universel. Si l’image ne le supporte pas, lisez le fichier dans un script de démarrage :

# exemple entrypoint.sh
export DB_PASSWORD=$(cat /run/secrets/db_password)
# puis lancer l'application

Étape 5 : déployer

docker stack deploy -c docker-compose.yml myapp

Ici docker stack deploy, pas docker-compose up. En mode Swarm, il faut la commande stack.

Étape 6 : vérifier

Entrer dans le conteneur MySQL :

docker exec -it <container-ID> sh
ls -la /run/secrets/

Vous verrez :

total 8
-r--r--r-- 1 root root 18 Dec 18 10:00 mysql_password
-r--r--r-- 1 root root 18 Dec 18 10:00 mysql_root_password

Lecture :

cat /run/secrets/mysql_root_password

Le mot de passe s’affiche — mais uniquement en mémoire, pas sur disque, pas dans les variables d’environnement.

Vérifier que docker inspect ne montre pas le mot de passe :

docker inspect <container-ID> | grep -i password

Seul un chemin comme MYSQL_ROOT_PASSWORD_FILE=/run/secrets/mysql_root_password apparaît — pas le mot de passe lui-même.

C’est la force de Docker Secrets : l’application lit le secret, l’extérieur ne voit pas le texte en clair.

Limites de Docker Secrets et alternatives

Docker Secrets n’est pas parfait. Principales limites :

Limite 1 : mode Swarm obligatoire

Gênant. En dev local, machine unique, il faut docker swarm init. Swarm sur une seule machine fonctionne, mais ça semble excessif.

Une fois Swarm activé, c’est docker stack deploy — plus docker-compose up. Il faut changer ses habitudes.

Limite 2 : secret immuable après création

Contenu en lecture seule. Pour changer le mot de passe, supprimer et recréer :

docker secret rm mysql_password
echo "NewPassword789" | docker secret create mysql_password -

Puis mettre à jour tous les services concernés :

docker service update --secret-rm mysql_password --secret-add mysql_password myapp_db

Plus lourd qu’une variable d’environnement + redémarrage.

Limite 3 : pas pour les conteneurs standalone

Avec docker run seul, pas de Docker Secrets. Il faut docker service create ou docker stack.

Peu pratique pour un test rapide — parfois on veut juste une base temporaire.

Alternative dev mono-machine : docker-compose file secrets

docker-compose propose des secrets file — sans Swarm, montage d’un fichier local comme secret.

version: '3.8'

secrets:
  db_password:
    file: ./secrets/db_password.txt

services:
  db:
    image: mysql:8.0
    secrets:
      - db_password
    environment:
      MYSQL_ROOT_PASSWORD_FILE: /run/secrets/db_password

Créer le fichier :

mkdir secrets
echo "MyPassword123" > secrets/db_password.txt

Attention : ajouter secrets/ à .gitignore !

Mieux que les variables d’environnement — le mot de passe n’apparaît pas dans docker inspect ni dans l’image. Mais moins sûr que Docker Secrets :

• Fichier en clair sur disque local
• Pas de chiffrement en transit
• Pas de gestion centralisée

Pour le dev local, souvent suffisant. En production, Swarm ou Kubernetes.

Astuces avancées

Quelques techniques utiles une fois les bases maîtrisées.

Astuce 1 : chemin de montage personnalisé

Par défaut /run/secrets/<nom_secret>, personnalisable :

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

services:
  myapp:
    image: myapp:latest
    secrets:
      - source: db_password
        target: /app/config/database.pwd
        mode: 0400

mode: 0400 = lecture owner uniquement.

Astuce 2 : multi-environnements

Mots de passe différents dev/test/prod, noms de secret identiques :

# production
docker secret create db_password prod_password.txt

# test (autre cluster Swarm)
docker secret create db_password test_password.txt

Le code lit /run/secrets/db_password sans connaître la valeur — déploiement identique, clusters différents.

Astuce 3 : rotation des secrets

Changer les mots de passe régulièrement. La rotation Docker demande un peu de manipulation :

# 1. Nouveau mot de passe
echo "NewPassword" | docker secret create db_password_v2 -

# 2. Mettre à jour le service
docker service update \
  --secret-rm db_password \
  --secret-add source=db_password_v2,target=/run/secrets/db_password \
  myapp_db

# 3. Supprimer l'ancien secret une fois stable
docker secret rm db_password

Le nouveau secret s’appelle db_password_v2, mais target garde /run/secrets/db_password — pas de changement de code.

Astuce 4 : créer depuis stdin

Sans laisser de trace sur disque :

echo "MySecretPassword" | docker secret create db_password -

Le - final = lecture depuis stdin. Pas de fichier temporaire.

Plus sûr, saisie manuelle (pas dans l’historique shell) :

docker secret create db_password -
# coller le mot de passe, Ctrl+D pour terminer

Comparaison d’autres outils de gestion des secrets

Matrice comparatif de quatre outils

Docker Secrets n’est pas la seule option. Selon la taille du projet et l’infrastructure :

En résumé :

• Petit projet, Docker Swarm → Docker Secrets suffit, gratuit et simple
• Production Kubernetes → K8s Secrets + External Secrets Operator vers Vault externe
• Grande entreprise, multi-cloud, haute sécurité → Vault
• Stack AWS complète → Secrets Manager, intégration RDS/Lambda

Pas d’outil « meilleur », seulement le plus adapté. Mon parcours : petit projet avec docker-compose file secrets → équipe agrandie, Docker Swarm + Docker Secrets → migration K8s, évaluation de Vault.

Chaque migration a un coût, mais la sécurité progresse.

Recommandations de choix

Comment décider ?

Si vous êtes…

Développeur solo / petit projet :

• Dev local : docker-compose file secrets
• VPS avec quelques services : Docker Swarm + Docker Secrets
• Budget serré : évitez Vault, trop lourd

Startup (10-50 personnes) :

• Docker : Docker Secrets
• K8s : K8s Secrets + External Secrets Operator (migration progressive vers Vault)
• Tout sur AWS : Secrets Manager

Grande entreprise :

• Multi-cloud : Vault quasi incontournable
• Audit et conformité : Vault
• Équipe sécurité dédiée : Vault
• Budget confortable : Vault

Arbre de décision simplifié :

Vous utilisez K8s ?
 └─ Oui → K8s Secrets, Vault si besoins avancés
 └─ Non → Docker Swarm ?
      └─ Oui → Docker Secrets
      └─ Non → Sur AWS ?
           └─ Oui → AWS Secrets Manager
           └─ Non → file secrets (dev) / Vault (prod)

Cas pratiques

Deux parcours réels :

Cas 1 : évolution d’une startup SaaS

Ami SaaS, 5 personnes au départ, tout en Docker sur un VPS. docker-compose + file secrets, mots de passe sur le serveur, gestion manuelle.

Six mois plus tard, levée seed, 15 personnes, architecture microservices. Migration vers Docker Swarm et Docker Secrets — gestion centralisée, plus de fichiers de mots de passe sur chaque serveur.

Un an après, série A, migration K8s. K8s Secrets + AWS Secrets Manager pour RDS/S3 + External Secrets Operator pour synchroniser.

Évaluation en cours de migration vers Vault — stratégie multi-cloud (GCP en backup), Secrets Manager trop lié à AWS.

L’architecture de sécurité évolue avec l’activité — inutile de viser la solution la plus complexe dès le départ.

Cas 2 : entreprise traditionnelle, approche directe

Ami dans une banque, containerisation l’an dernier. Conformité stricte → Vault dès le départ.

Courbe d’apprentissage raide, mais :

• Journaux d’audit complets
• Secrets dynamiques (identifiants DB temporaires, expiration auto)
• Intégration LDAP pour les permissions

Deux personnes-mois de mise en place et formation, puis faible coût de maintenance.

Contextes différents, choix différents. Vault peut être excessif pour une petite structure ; Docker Secrets peut être insuffisant pour une grande entreprise.

Checklist des bonnes pratiques en production

Mesures de sécurité immédiates

Avec ou sans Docker Secrets, faites ceci maintenant :

✅ Vérifier l’historique Git

# rechercher des mots-clés sensibles
git log -p -S 'password' -S 'secret' -S 'api_key'

# vérifier si .env a été commité
git log --all --full-history -- .env

Si trouvé, nettoyer avec git filter-repo ou BFG Repo-Cleaner, puis changer immédiatement tous les mots de passe exposés.

✅ Configurer .gitignore

# .gitignore
.env
*.env
secrets/
db_password.txt
*_password.txt
*_secret.txt
*.pem
*.key

Sans exception.

✅ Activer GitHub Secret Scanning

Sur GitHub : Settings → Security → Secret scanning alerts. Alerte automatique si une clé est poussée.

Gratuit pour les dépôts publics ; privés nécessitent Pro/Team/Enterprise. Les publics en ont surtout besoin — activez-le.

✅ Changer tous les identifiants potentiellement exposés

Inventaire :

• Mots de passe de base de données
• Clés API (AWS/OpenAI/Stripe, etc.)
• Secret JWT
• OAuth client secrets
• Clés privées SSL

Tout ce qui peut l’être. Mieux vaut corriger tard que jamais.

Étapes d’implémentation Docker Secrets

Vous choisissez Docker Secrets ? Ordre recommandé :

Étape 1 : inventorier les informations sensibles

✓ Mot de passe root MySQL
✓ Mot de passe application DB
✓ Mot de passe Redis
✓ Clé de signature JWT
✓ Clés API tierces (paiement/SMS, etc.)
✓ Clés privées SSL
✓ OAuth client secret

Étape 2 : choisir l’outil

Docker Secrets, K8s Secrets ou Vault — choisissez-en un, migration possible plus tard.

Étape 3 : créer les secrets

# Docker Swarm
docker swarm init
docker secret create db_password <(echo "mot-de-passe")
docker secret create api_key <(echo "clé")

# docker-compose file secrets
mkdir secrets
echo "mot-de-passe" > secrets/db_password.txt
echo "clé" > secrets/api_key.txt
chmod 600 secrets/*

Étape 4 : modifier la configuration

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Remplacer environment par secrets dans docker-compose.yml :

# avant
services:
  app:
    environment:
      DB_PASSWORD: "hardcoded_password"  # ❌

# après
services:
  app:
    secrets:
      - db_password
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password  # ✅

Étape 5 : adapter le code (si nécessaire)

Si le framework ne supporte pas _FILE :

// exemple Node.js
const fs = require('fs');
const dbPassword = process.env.DB_PASSWORD_FILE
  ? fs.readFileSync(process.env.DB_PASSWORD_FILE, 'utf8').trim()
  : process.env.DB_PASSWORD;

Étape 6 : tester

En environnement de test :

• Démarrage OK
• Lecture correcte du mot de passe
• docker inspect sans texte en clair
• Fonctionnalités OK

Étape 7 : déploiement production

Déployer en prod. Par prudence, garder temporairement l’ancienne config en fallback, supprimer une fois stable.

Maintenance sécurité continue

Docker Secrets n’est pas « fini » — maintenance continue :

Rotation des clés (tous les 90 jours recommandé)

Rappel calendrier trimestriel. Surtout après un départ.

Surveiller les accès aux secrets

Avec Vault, consulter régulièrement les journaux d’audit.

Docker Secrets et K8s Secrets n’ont pas d’audit natif — compléter avec Falco si besoin.

Principe du moindre privilège

Chaque service n’accède qu’aux secrets nécessaires :

services:
  frontend:
    secrets:
      - api_key  # frontend : clé API seulement

  backend:
    secrets:
      - db_password  # backend : mot de passe DB
      - api_key

Outils de scan de secrets

Intégrer au CI/CD :

• trufflehog : historique Git
• git-secrets : bloquer les commits sensibles
• gitleaks : détection dans le code

Pre-commit hook — ça évite beaucoup d’erreurs.

Cinq pièges à éviter

1. Ne pas passer de secrets via ARG

# ❌ incorrect
ARG DB_PASSWORD=secret
ENV DATABASE_URL=postgres://user:${DB_PASSWORD}@db/myapp

ARG reste dans l’historique de build — visible avec docker history.

2. Ne pas imprimer les secrets sur stdout

# ❌ incorrect
password = open('/run/secrets/db_password').read()
print(f"Using password: {password}")  # va dans docker logs !

Les logs capturent stdout. Difficile à effacer ensuite.

3. Ne pas réutiliser le même secret entre environnements

Dev, test et prod : mots de passe séparés. Une fuite en test ne doit pas compromettre la prod.

4. Ne pas copier un secret vers un autre chemin dans le conteneur

# ❌ incorrect
cp /run/secrets/db_password /app/config/password.txt

/run/secrets est tmpfs (mémoire). Copier ailleurs peut écrire sur disque — moins sûr.

Lisez directement depuis /run/secrets.

5. Ne pas oublier l’expiration et la rotation

Avec des secrets dynamiques à expiration (Vault), configurez renouvellement ou rotation automatique. Évitez la panne nocturne quand tout expire.

Conclusion

En une phrase : ne mettez pas les mots de passe là où on peut les voir.

Les variables d’environnement semblent pratiques, mais docker inspect expose tout. Les ENV du Dockerfile sont pires — permanent dans les couches d’image. Beaucoup d’incidents viennent de ces « raccourcis ».

Docker Secrets n’est pas parfait — Swarm requis, immuable, peu pratique en dev solo. Mais il résout l’essentiel : stockage chiffré, transit chiffré, absent des variables d’environnement et des images. Pour Swarm, c’est la solution la plus directe.

Kubernetes → K8s Secrets ; entreprise → Vault ; tout AWS → Secrets Manager. Pas d’outil universel, seulement le bon pour votre contexte.

Agissez aujourd’hui :

• Des mots de passe dans l’historique Git ?
• .env dans .gitignore ?
• docker inspect montre-t-il vos mots de passe ?

Si oui, oui, oui — il est temps de corriger. Pas besoin de Vault immédiatement ; passer des variables d’environnement aux file secrets améliore déjà la situation.

La sécurité est un processus continu, pas une configuration unique. Rotation, surveillance, scan — ces habitudes comptent autant que l’outil.

Partagez avec votre équipe. La gestion des secrets concerne tout le monde — standards communs et revues régulières réduisent les risques.

Bonne continuation — et plus d’alertes à 3 h du matin.

Ressources :

• Documentation Docker — Manage sensitive data with Docker secrets
• Documentation HashiCorp Vault
• AWS Secrets Manager
• trufflehog — scan de clés Git