Sortir les secrets des fichiers .env et des pipelines avec Vault

Déplacer un mot de passe de .env vers une variable CI ne change pas forcément qui peut le lire ni combien de temps il reste valide. L'objectif est de donner à chaque workload un accès limité, traçable et renouvelable, puis de prouver que l'ancienne clé cesse de fonctionner.

1. Inventorier sans recopier les valeurs

Prenez une application pilote et documentez pour chaque secret : propriétaire, usage, environnement, emplacement, consommateurs, droits, expiration et méthode de révocation. Stockez des identifiants de référence, jamais les valeurs, dans cet inventaire.

Prérequis : Vault de production déjà déployé avec TLS, stockage et sauvegardes testés, méthode d'authentification configurée, CLI compatible et accès administrateur pour créer une politique. N'utilisez pas le mode dev. Séparez staging et production.

Dans une copie autorisée du dépôt applicatif :

Ces commandes repèrent des emplacements, pas toutes les fuites. Lancez aussi l'analyse de secrets de votre forge sur l'historique complet et un contrôle pré-commit. Triez les alertes en limitant l'affichage des valeurs ; inspectez aussi caches CI, logs et artefacts. Un .gitignore ajouté aujourd'hui ne retire rien de l'historique.

Architecture proposée : identité du workload → authentification Vault → politique minimale → secret délivré dans un fichier temporaire protégé → application. Le pipeline construit l'image sans secret de production ; le runtime obtient le sien séparément.

2. Migrer un secret et répéter sa rotation

Supposons un moteur KV v2 existant monté sous secret/. KV versionne des valeurs statiques ; il ne renouvelle pas automatiquement une clé API chez son fournisseur. Préparez shop-read.hcl :

Puis, avec l'identité administrateur :

Associez cette politique à l'authentification du workload. Avec OIDC/JWT, liez explicitement émetteur, audience, dépôt, branche et environnement autorisés ; avec Kubernetes, namespace et ServiceAccount. La configuration exacte dépend de votre méthode existante. N'accordez ni root, ni accès global à secret/*, ni politique de production aux PR externes.

Créez la nouvelle clé chez le fournisseur avec les droits minimaux. Pour l'enregistrer sans valeur dans l'historique shell, utilisez Bash depuis un terminal autorisé, avec le traçage désactivé :

Cette écriture remplace les données à ce chemin par le champ fourni : choisissez un chemin dédié ou préparez explicitement les autres champs. Les versions précédentes restent accessibles aux identités qui y ont droit.

Pour un test sous l'identité applicative déjà authentifiée, utilisez un répertoire runtime précréé, réservé à ce compte, sur stockage temporaire :

Le déplacement dans le même système de fichiers rend le remplacement atomique. Configurez l'application pour lire ce fichier et recharger sa valeur ; ne faites jamais cat dessus dans un job CI. Cet exemple valide la distribution initiale, pas le renouvellement automatique. En production, utilisez un agent ou une intégration maintenue gérant authentification, renouvellement, permissions et rechargement.

Testez la nouvelle clé sur un endpoint non destructif, puis déployez progressivement. Si le fournisseur autorise deux clés simultanées : créez → distribuez → vérifiez tous les consommateurs → révoquez l'ancienne. Sinon, planifiez la courte interruption ou une bascule coordonnée.

Préférez les credentials dynamiques de base de données ou les sessions cloud temporaires lorsque l'intégration le permet. Donnez-leur une durée compatible avec les traitements, surveillez renouvellement et expiration, et testez une panne du gestionnaire. Ne demandez pas un nouveau secret à chaque requête HTTP.

3. Traiter une fuite et sécuriser le retour arrière

Une clé publiée dans Git doit être révoquée ou renouvelée chez son émetteur avant tout nettoyage d'historique. Identifiez sa portée et la période d'exposition, examinez les usages, puis remplacez-la partout : jobs, serveurs, caches et images concernés.

Après gel des pushes, sauvegarde restreinte et coordination avec les contributeurs, une copie de travail dédiée peut retirer un fichier de l'historique avec une version de git-filter-repo prenant en charge ce mode :

Cette opération réécrit l'historique et les identifiants de commits. Elle ne nettoie ni les autres chemins ni les clones, forks, caches et références distantes à elle seule. Organisez le remplacement des références et les nouveaux clones avec l'administrateur de la forge ; n'improvisez pas un force-push sur le dépôt partagé.

Après migration, vérifiez : accès refusé à un chemin voisin, ancienne clé rejetée par le fournisseur, redémarrage réussi de l'application et aucun secret dans les logs. Surveillez lectures inhabituelles, refus Vault, échecs de renouvellement, 401/403 applicatifs et disponibilité du gestionnaire.

Le rollback restaure la configuration de lecture précédente seulement si son credential reste sain. Ne réactivez jamais une clé compromise ; émettez une nouvelle clé. Une ancienne version KV n'est pas une révocation annulée chez le fournisseur.

La centralisation ajoute une dépendance de démarrage et de renouvellement. Prévoyez haute disponibilité, sauvegardes chiffrées, cache mémoire borné par la durée de validité et procédure de secours auditée. Maintenez les journaux d'audit sans valeurs de secrets et exercez régulièrement la rotation.

Sources : HashiCorp, Vault KV v2, GitHub, retirer des données sensibles.