Gestion des secrets : le hub pour s'y retrouver

Un mot de passe commité « temporairement » dans Git, retrouvé trois mois plus tard par un attaquant : le commit était supprimé, mais l'historique conserve tout. La gestion des secrets consiste à éviter exactement ce scénario, et tous ses cousins. Cette page est le point d'entrée de la section : elle pose les repères et vous oriente vers le bon guide selon votre besoin, du concept fondamental au coffre-fort concret. Chaque carte mène à une page dédiée qui traite son sujet en profondeur.

La section suit une logique simple : d'abord comprendre (qu'est-ce qu'un secret, comment il vit et fuit), puis outiller (coffres, détection, identités). Les concepts sont la matière ; les guides outils la déclinent ensuite de bout en bout.

Les fondamentaux : comprendre avant d'outiller

Commencez par ces concepts. Ils forment la matière que tous les outils implémentent ensuite. Si vous débutez, lisez-les dans cet ordre.

Qu'est-ce qu'un secret ? Secret contre configuration, et la règle qui tranche.

Inventorier et classer ses secrets On ne protège bien que ce que l'on connaît : registre, découverte, classification.

Cycle de vie d'un secret De la génération à la destruction, en passant par la rotation.

Le chiffrement des secrets Chiffrement en enveloppe, HSM et KMS.

Secrets statiques : le problème Pourquoi les credentials persistants posent problème.

Statiques vs dynamiques Comparer les trois modèles : statique, dynamique, identité fédérée.

Identité machine (workload identity) SPIFFE, SPIRE et l'authentification machine à machine.

Le problème du secret zéro Qui donne le premier secret ? La réponse par l'attestation.

Où les secrets fuient, et comment réagir

Les secrets ne fuient pas que dans le code : historique Git, images conteneur, journaux, variables. Voici les surfaces d'exposition et la conduite à tenir face à une fuite.

Secrets dans le code et Git Pourquoi supprimer un commit ne suffit pas.

Fuites : journaux, Docker, variables Les fuites invisibles, des logs aux images conteneur.

Détecter les secrets exposés Gitleaks, TruffleHog, Trivy : stratégie combinée.

Réagir à un secret compromis Révoquer, tourner, analyser : la procédure d'incident.

Les secrets selon l'environnement

Les contraintes changent selon le terrain. Ces guides traitent les deux environnements les plus exposés.

Secrets dans les pipelines CI/CD GitHub Actions, GitLab CI et l'authentification OIDC.

Secrets Kubernetes Secrets natifs, External Secrets Operator, CSI Driver.

Les coffres et gestionnaires

Une fois les concepts en place, voici les outils qui les déclinent de A à Z : coffres pour applications, gestionnaires pour équipes, chiffrement de fichiers.

HashiCorp Vault La référence : stockage central, secrets dynamiques, PKI, transit.

OpenBao Le fork open source de Vault, sous gouvernance ouverte.

Infisical Plateforme moderne de gestion des secrets.

Mozilla SOPS Chiffrer des fichiers de configuration versionnés.

Passbolt Gestionnaire de mots de passe pour équipes.

Bitwarden Gestionnaire de mots de passe, usage humain.

Vaultwarden Serveur Bitwarden léger, auto-hébergé.

Teller Injecter les secrets depuis plusieurs backends.

Les grands principes en bref

Quel que soit l'outil, une gestion saine repose sur quelques principes que les guides détaillés reprennent chacun à leur niveau.

Séparer le code et les secrets : le code source ne contient jamais de secret ; il est injecté au démarrage depuis une source sûre.
Chiffrer, centraliser, tracer : les secrets vivent dans un coffre chiffré, à un point unique, avec chaque accès audité (qui, quand).
Moindre privilège : chaque secret donne accès au strict nécessaire, jamais un accès admin « par facilité ».
Rotation et révocation : un secret doit pouvoir être changé et invalidé vite ; s'il est pénible à tourner, il ne le sera pas.
Automatiser : l'humain est le maillon faible, on automatise génération, distribution et rotation.
Réduire les secrets persistants : privilégier les secrets dynamiques (générés à la demande, à durée de vie courte) et l'identité de charge (prouver son identité plutôt que détenir un secret durable).

Qui est concerné

La gestion des secrets n'est pas que l'affaire de la sécurité : elle touche toute personne qui manipule du code, de l'infrastructure ou des données. Chaque rôle a sa part.

Profil	Responsabilité	Priorité
Développeur	Ne jamais commiter de secret, utiliser l'injection au démarrage	Quotidienne
Ops / SRE	Configurer les coffres, automatiser rotation et révocation	Critique
DevSecOps	Détecter les secrets exposés, intégrer les scans en CI/CD	Continue
RSSI	Politique de gestion, audit de conformité	Stratégique
Tech Lead	Revue de code, culture d'équipe, choix des outils	Encadrement

Choisir la bonne approche selon votre besoin

Il n'y a pas d'outil universel. Le bon choix dépend de qui ou quoi consomme le secret. Voici les quatre cas les plus courants.

Pour un humain : un gestionnaire de mots de passe (Bitwarden, Passbolt), une MFA (authentification à plusieurs facteurs) obligatoire, un partage contrôlé et audité.
Pour une application simple : un coffre central (Vault, Infisical), l'injection au démarrage plutôt qu'un fichier .env versionné, une rotation programmée.
Pour une plateforme cloud-native : des secrets dynamiques, une identité de charge (SPIFFE, IAM cloud), des certificats courts et des accès temporaires en CI/CD via OIDC.
Pour du legacy : un secret statique fortement contrôlé, roté aussi souvent que possible, avec surveillance des accès et moindre privilège strict.

Les pièges courants

Ces erreurs reviennent même dans les organisations qui utilisent déjà un coffre. Chacune a une parade, détaillée dans les guides liés plus haut.

Piège	Conséquence	Parade
Secret statique partagé entre services	Impossible d'attribuer un incident	Identité ou secret distinct par charge
Rotation manuelle rare	Secret valide trop longtemps	Secrets dynamiques ou rotation automatisée
Kubernetes Secrets comme seul coffre	Faux sentiment de sécurité	Chiffrement etcd + RBAC + External Secrets
Jeton cloud longue durée en CI/CD	Compromission durable	OIDC, accès temporaires, identité de charge
Secrets en variables d'environnement seules	Exposition dans les journaux et les dumps	Injection contrôlée, durée de vie minimale
Même secret en dev, préprod et prod	Une fuite en dev compromet la prod	Secrets séparés par environnement
Commiter « temporairement »	L'historique Git conserve tout	Hook pre-commit avec détection de secrets

Du principe au contrôle : l'ancrage SOCLE

Ces principes ne sont pas des voeux : le référentiel du site les traduit en exigences vérifiables. Le modèle de menaces SOCLE pour les secrets recense les vecteurs d'attaque (secret en clair, jeton volé, OIDC mal configuré) et les relie aux exigences du domaine secrets (inventaire, coffre chiffré, accès scopés et tracés, rotation, identités éphémères, détection de fuite). Chaque concept fondamental ci-dessus est rattaché à ces exigences.

À retenir

Le code source ne doit jamais contenir de secrets : c'est la règle de base.
Un secret statique doit être l'exception, pas la norme : visez les secrets dynamiques et l'identité de charge.
Un secret dynamique bat un secret longue durée : il réduit la fenêtre d'exploitation et se révoque tout seul.
Pour le machine à machine, pensez identité avant mot de passe : SPIFFE, workload identity, OIDC.
Réduire progressivement les secrets persistants, pas tout d'un coup : on commence par les plus durables, partagés et critiques.

Ressources externes

OWASP Secrets Management Cheat Sheet, la référence des bonnes pratiques.
HashiCorp Vault Documentation, secrets statiques et dynamiques.
SPIFFE / SPIRE, identités de charge.
NIST SP 800-57, gestion des clés cryptographiques.