Gestion des secrets : coffres et rotation

Prérequis : cours DevOps 8.2 (secrets et fuites) — approfondissement ops.

Pourquoi

.env suffit en solo ; en équipe/échelle, il faut : qui a vu quoi, rotation sans downtime, audit. Le coffre (Vault, AWS Secrets Manager, Doppler…) apporte le contrôle — au prix d'une pièce d'infra de plus à opérer.

Concepts

• Coffre : stockage chiffré + contrôle d'accès fin (qui lit quoi) + audit (qui a lu quand) + rotation assistée. L'app récupère au démarrage (jamais de secret dans l'image !).
• Secrets dynamiques : générés à la demande, courte vie (identifiants DB de 1 h pour l'app !). Volés = vite périmés. Le top, quand l'infra le permet.
• Rotation sans downtime : double validité temporaire (ancien + nouveau acceptés), déployer partout, révoquer l'ancien. Jamais de « big bang » de secret un vendredi.
• Hors coffre (solo/PME) : .env 600 + backup chiffré + inventaire + rotation calendrier. Le coffre attendra la 2e personne qui en a besoin.

Exemple : rotation propre (mot de passe DB)

1. Créer newpass, autoriser old+new côté base
2. Redéployer apps avec newpass (rolling)
3. Vérifier logs : plus d'usage de old
4. Révoquer old. 5. Noter date + prochaine

Cas réel

Rotation « big bang » un vendredi 17h : 2 services oubliés (worker, cron) avec l'ancien, down silencieux le week-end, découvert lundi. Depuis : double validité + checklist des consommateurs (l'inventaire !) + jamais vendredi.

Pièges

• Coffre sans backup chiffré testé : le coffre mort = tous les secrets perdus = tout mort. Le coffre se sauvegarde comme le reste (plus !).
• Secret dans l'image Docker (« ça simplifie le deploy ») : toute personne avec l'image a le secret. Jamais.
• Inventaire absent : « qui utilise cette clé ? » sans réponse = rotation impossible = jamais faite.

À retenir

Coffre quand l'échelle l'exige (sinon .env rigoureux), dynamiques si possible, rotation double-validité, coffre sauvegardé.