Gestion des secrets en production : Vault, SOPS et rotation automatique

Chaque semaine, des secrets — clés API, mots de passe de bases de données, certificats TLS, tokens OAuth — sont accidentellement exposés dans des dépôts git publics, des logs applicatifs ou des images Docker. GitGuardian a détecté plus de 12 millions de secrets exposés sur GitHub en 2025, une augmentation de 28 % par rapport à l'année précédente. Ces incidents ne sont pas des erreurs de débutants : des équipes expérimentées les commettent régulièrement, parce que la gestion manuelle des secrets dans des environnements modernes à haute vélocité est structurellement incompatible avec la sécurité. La solution n'est pas plus de discipline — c'est l'automatisation et la centralisation via des outils de secrets management dédiés.

Pourquoi les .env files et les variables d'environnement ne suffisent pas

Le fichier .envest devenu le réflexe universel pour stocker les secrets en développement. Mais il présente des failles structurelles qu'aucune convention d'équipe ne peut compenser entièrement. Un .env commité par erreur (le .gitignoreoublié, la PR d'un contributeur externe, le git add -Aun peu trop enthousiaste) expose l'ensemble des secrets de production à toute personne ayant accès au dépôt — y compris dans l'historique git, où ils restent visibles même après suppression.

Les variables d'environnement injectées par CI/CD (GitHub Actions secrets, GitLab CI variables) sont meilleures, mais posent d'autres problèmes : les secrets sont statiques (pas de rotation automatique), leur gestion est dispersée entre plusieurs plateformes sans audit centralisé, et leur accès est binaire (accès ou pas d'accès, sans granularité par environnement ou par service). Pour une architecture sécurisée complète, ces limites s'accumulent rapidement — et l'absence de rotation signifie qu'un secret compromis reste dangereux indéfiniment jusqu'à intervention manuelle.

HashiCorp Vault : la référence pour les équipes avec des besoins avancés

Vault est un serveur de secrets centralisé qui va bien au-delà du simple stockage sécurisé. Sa fonctionnalité la plus puissante est la génération de secrets dynamiques: au lieu de stocker un mot de passe de base de données permanent, Vault génère des credentials temporaires à la demande, avec une durée de vie configurable (1 heure, 24 heures). Quand le TTL expire, les credentials sont automatiquement révoqués. Résultat : même si un secret est intercepté, sa fenêtre d'exploitation est limitée.

• Secret engines : Vault supporte nativement les secrets dynamiques pour PostgreSQL, MySQL, MongoDB, AWS IAM, Azure, GCP, SSH, PKI (génération de certificats TLS). Chaque engine génère des credentials sur demande et les révoque automatiquement.
• Auth methods: les applications s'authentifient auprès de Vault via des méthodes adaptées à leur environnement (Kubernetes ServiceAccount, AWS IAM role, JWT/OIDC, AppRole). Pas de credentials Vault stockés dans le code.
• Audit log: chaque accès à un secret est loggé avec l'identité du demandeur, le secret accédé et le timestamp. Indispensable pour les audits de conformité (SOC2, ISO27001).
• Lease & renewal: chaque secret a un bail (lease) qui peut être renouvelé par l'application ou révoqué immédiatement en cas d'incident.

La contrepartie de Vault est sa complexité opérationnelle. Le déploiement initial, le unseal process, la haute disponibilité et la gestion des politiques d'accès nécessitent une expertise dédiée. HCP Vault (HashiCorp Cloud Platform) propose une version managée qui élimine la majeure partie de cet overhead.

SOPS : les secrets chiffrés dans git

SOPS (Secrets OPerationS, créé par Mozilla) adopte une philosophie différente : plutôt que d'extraire les secrets du dépôt git, elle les y laisse — mais chiffrés. SOPS chiffre les valeurs des fichiers YAML, JSON ou ENV en utilisant des clés gérées par AWS KMS, GCP KMS, Azure Key Vault, ou des clés PGP locales. Le fichier chiffré peut être commité en toute sécurité dans git ; seuls les membres autorisés (ceux qui ont accès à la clé KMS ou PGP correspondante) peuvent le déchiffrer.

SOPS s'intègre naturellement dans les workflows GitOps (ArgoCD, Flux) et Terraform : les secrets vivent dans le même dépôt que l'infrastructure, versionnés et auditables, sans jamais être exposés en clair. La commande sops --decrypt secrets.yamlproduit le fichier en clair en mémoire sans jamais l'écrire sur disque. C'est le choix privilégié pour les équipes qui veulent la traçabilité git des secrets sans la complexité d'un serveur Vault.

AWS Secrets Manager, GCP Secret Manager : les options cloud-native

Si votre infrastructure est intégralement sur un cloud provider, les solutions natives sont souvent le meilleur point d'entrée. AWS Secrets Managerstocke et distribue les secrets avec rotation automatique native pour RDS, Redshift et ElastiCache. L'intégration avec IAM permet de contrôler finement quel rôle peut lire quel secret. Le coût est de 0,40 $/secret/mois + 0,05 $ pour 10 000 requêtes API — négligeable par rapport à la valeur de sécurité apportée.

GCP Secret Manager offre une intégration native avec les Workload Identity et les serviceaccounts Kubernetes, ce qui en fait le choix naturel pour les workflows GKE. Azure Key Vaultpousse l'intégration encore plus loin avec les Managed Identities Azure AD : un pod ou une VM peut accéder aux secrets sans jamais manipuler de credentials, l'authentification se faisant via l'identité de la ressource elle-même.

Rotation des secrets : l'étape souvent oubliée

Stocker les secrets de façon sécurisée n'est que la moitié du travail. La rotation régulière des secrets est tout aussi critique : un secret non rotatif est un secret qui, une fois compromis, reste dangereux indéfiniment. La rotation manuelle est un anti-pattern — elle est oubliée, retardée et crée des fenêtres de vulnérabilité lors des transitions.

La rotation automatique doit être conçue dès le départ, pas ajoutée après coup. Les applications doivent gérer le changement de secret sans interruption de service : soit via un mécanisme de dual-credential (l'ancien et le nouveau secret sont valides pendant une fenêtre de transition), soit via des secrets à durée de vie courte (comme les credentials dynamiques Vault) qui sont renouvelés automatiquement avant expiration. La gestion des tokens de connexion suit les mêmes principes de rotation et de révocation.

Intégration CI/CD : les pièges à éviter

Le CI/CD est souvent le maillon faible de la chaîne de secrets. Quelques règles absolues :

• Ne jamais afficher les secrets dans les logs de pipeline, même “temporairement pour déboguer”. Les logs CI sont souvent accessibles à des personnes extérieures à l'équipe core.
• Préférer l'injection via un vault (OIDC trust entre GitHub Actions/GitLab CI et AWS/GCP/Vault) plutôt que des secrets statiques stockés dans la plateforme CI. L'OIDC trust permet au job CI de s'authentifier avec une identité éphémère et d'obtenir des credentials temporaires — pas de secret longue durée à gérer ou à faire tourner.
• Scanner les dépôts git avec des outils comme Gitleaks, TruffleHog ou GitGuardian en pre-commit hook et en CI. Pour une approche complète de la sécurisation du pipeline, voir sécuriser son pipeline CI/CD.

“Un secret en clair dans un dépôt git n'est pas un incident de sécurité — c'est une certitude de compromission future. La question n'est pas si, mais quand.”

La gestion des secrets n'est pas un problème à résoudre une fois — c'est une discipline à maintenir dans la durée, avec des outils adaptés à l'échelle et à la maturité de votre organisation. Pour auditer votre gestion actuelle des secrets et mettre en place une infrastructure vault adaptée à vos contraintes, nous intervenons de l'audit à l'implémentation sur des stacks Vault, SOPS et cloud-native.