Vault : secrets dynamiques vs statiques

Les secrets dynamiques sont la vraie promesse de Vault : au lieu de stocker des credentials permanents que tout le monde partage, Vault génère des identifiants uniques, temporaires et révocables pour chaque workload.

Ce guide explique la différence entre secrets statiques et dynamiques, le modèle lease/TTL, et comment choisir le bon moteur selon votre besoin.

Terminologie

Dans ce guide, le terme secrets dynamiques désigne au sens large tous les accès temporaires émis par Vault. Selon le moteur, il peut s’agir d’un mot de passe (Database), d’un certificat X.509 (PKI), d’un certificat SSH signé ou OTP (SSH), ou d’un credential cloud (AWS, Azure, GCP).

Pourquoi les secrets permanents posent problème

Le modèle classique de gestion des secrets :

Problèmes :

Risque	Conséquence
Credential partagé	Si compromis, toutes les apps sont exposées
Pas de traçabilité	Impossible de savoir quelle app a fait quoi
Révocation difficile	Changer le mot de passe impacte toutes les apps
Rotation manuelle	Oublis, fenêtres d’exposition longues
Secrets dans le code	Fuites via Git, logs, variables d’environnement

Glissez pour voir

Le vrai risque

Un secret permanent compromis reste valide jusqu’à sa rotation manuelle. Entre la compromission et la détection, des semaines peuvent s’écouler.

Secrets statiques vs dynamiques

Secret statique (KV)

Vault stocke un secret que vous avez créé. Le secret existe indépendamment de Vault et ne change pas automatiquement.

# Vous créez le secret
vault kv put secret/myapp/db password="secret123"

# Vous le lisez
vault kv get secret/myapp/db

Cas d’usage :

• Clés API tierces imposées par le fournisseur
• Secrets legacy non migrables
• Configuration statique (URLs, paramètres)

Secret dynamique

Vault génère un secret à la demande, avec une durée de vie limitée. Le secret n’existait pas avant la requête et sera révoqué à expiration.

# Vault génère un nouveau user/password PostgreSQL
vault read database/creds/readonly

# Sortie : credentials uniques, valides 1 heure
Key                Value
---                -----
lease_id           database/creds/readonly/abcd1234
lease_duration     1h
username           v-token-readonly-xyz123
password           A1B2c3D4e5F6g7H8

Cas d’usage :

• Accès base de données (PostgreSQL, MySQL, MongoDB)
• Credentials cloud (AWS, GCP, Azure)
• Certificats TLS (PKI)
• Accès SSH (certificats signés)

Le modèle lease / TTL / révocation

Chaque secret dynamique est associé à un lease (bail) qui définit sa durée de vie.

Lease

Le lease est un identifiant unique qui référence le secret émis :

lease_id: database/creds/readonly/abcd1234-5678-90ef-ghij-klmnopqrstuv

Vault stocke ce lease et sait :

• Quel secret a été émis
• À qui (quel token)
• Quand il expire
• Comment le révoquer

TTL (Time To Live)

Exemples de TTL fréquents :

TTL	Cas d’usage
1h	Accès DB pour un job batch
24h	Session de développement
72h	Credentials CI/CD
30 jours	Certificats TLS services

Glissez pour voir

Renouvellement

Avant expiration, le client peut prolonger le lease :

vault lease renew database/creds/readonly/abcd1234

Le renouvellement est limité par le max_ttl configuré sur le rôle.

Qui renouvelle ?

En production, le vrai sujet n’est pas la commande vault lease renew, mais l’architecture : qui renouvelle (l’app, un sidecar, Vault Agent), quand, et que se passe-t-il si le renouvellement échoue ? Planifiez cette stratégie avant déploiement.

Révocation

À tout moment, vous pouvez révoquer un lease :

# Révoquer un lease spécifique
vault lease revoke database/creds/readonly/abcd1234

# Révoquer tous les leases d'un préfixe
vault lease revoke -prefix database/creds/readonly

Vault exécute l’action de nettoyage : pour une base de données, il supprime l’utilisateur créé. Pour AWS, il révoque les credentials IAM.

Révocation = action sur le système cible

La révocation ne se limite pas à invalider une entrée dans Vault : selon le moteur, Vault exécute aussi les actions de nettoyage prévues sur le système cible, par exemple suppression d’un utilisateur DB ou invalidation de credentials cloud.

Dynamic role vs static role

Certains moteurs (Database, AWS) supportent deux modes.

Pas universel

Le couple “dynamic role / static role” n’existe pas de manière identique dans tous les moteurs Vault. C’est surtout un modèle utile pour comprendre Database et certains usages AWS.

Dynamic role

Vault crée un nouveau credential à chaque requête :

# Chaque appel crée un nouvel utilisateur DB
vault read database/creds/app-role
# → username: v-token-app-xyz123

vault read database/creds/app-role
# → username: v-token-app-abc456  (différent!)

Avantages :

• Credentials uniques par workload
• Traçabilité parfaite
• Révocation granulaire

Inconvénients :

• Nécessite que l’app gère le renouvellement
• Plus de credentials à gérer côté système cible

Static role

Vault gère un credential existant et le fait tourner automatiquement :

# Toujours le même utilisateur, mais password roté
vault read database/static-creds/legacy-app
# → username: legacy_app_user (fixe)
# → password: RotatedPass123 (changé périodiquement)

Avantages :

• Compatible avec les apps legacy qui attendent un user fixe
• Rotation automatique sans changer l’architecture

Inconvénients :

• Credential partagé si plusieurs apps utilisent le même static role
• Moins de traçabilité

Static role ≠ secret statique

Un static role n’est pas un secret KV. Vault gère le credential et le fait tourner automatiquement. La clé est fixe, la valeur change.

Tableau de choix des moteurs

Besoin	Moteur Vault	Type	TTL typique
Credentials PostgreSQL/MySQL	Database	Dynamique	1-24h
Compte DB legacy à rotation	Database (static role)	Géré	rotation 24h
Credentials AWS IAM	AWS	Dynamique	1-12h
Access key AWS existante	AWS (static role)	Géré	rotation 24h
Certificats TLS	PKI	Dynamique	30-90 jours
Accès SSH aux serveurs	SSH	Dynamique	5 min - 24h
Clés API tierces imposées	KV	Statique	N/A
Configuration applicative	KV	Statique	N/A

Glissez pour voir

Arbre de décision

Le credential peut-il être généré à la demande ?
├── Oui → Secret dynamique
│   ├── Base de données → Database secrets engine
│   ├── AWS → AWS secrets engine
│   ├── Azure → Azure secrets engine
│   ├── GCP → GCP secrets engine
│   ├── Certificat TLS → PKI secrets engine
│   └── Accès SSH → SSH secrets engine
│
└── Non (imposé par un tiers)
    └── KV secrets engine

Audit et traçabilité par identité

Avec les secrets dynamiques, chaque workload obtient un credential unique. La traçabilité devient bien plus simple :

Bénéfices :

Aspect	Avant (partagé)	Après (dynamique)
Audit DB	”admin a fait X"	"v-token-app-b a fait X”
Compromission	Toutes les apps exposées	Une seule app exposée
Révocation	Impacte tout le monde	Révoque juste l’app compromise
Rotation	Coordination manuelle	Automatique par TTL

Glissez pour voir

Corrélation avec les logs Vault

Les logs d’audit Vault tracent :

• Quel token a demandé le credential
• Quelle méthode d’auth a obtenu ce token
• L’heure exacte de l’émission

Vous pouvez corréler :

1. Log Vault : token abc123 a demandé database/creds/readonly à 10:00
2. Log PostgreSQL : user v-token-readonly-xyz a exécuté SELECT * FROM users à 10:05
3. Conclusion : l’app avec token abc123 a lu la table users

Conditions de la traçabilité

Cette corrélation est nette si l’authentification Vault est bien conçue, les rôles bien séparés, et les logs (Vault, DB, app) correctement horodatés et centralisés. Les secrets dynamiques simplifient la traçabilité, mais ne la rendent pas automatique.

Quand rester sur KV (secrets statiques)

Les secrets dynamiques ne sont pas toujours possibles. Utilisez KV quand le secret est imposé par un tiers ou non générable par Vault :

Cas	Exemple	Pourquoi KV
Clé API tierce	Stripe, Twilio, SendGrid	Le fournisseur impose la clé
Secret partagé partenaire	Token d’intégration B2B	Négocié manuellement
Licence logicielle	Clé de licence propriétaire	Non générable
Credential legacy	Mot de passe d’un système non supporté	Pas de plugin Vault
Configuration statique	URLs, paramètres non secrets	Pas besoin de dynamique

Glissez pour voir

Rotation manuelle avec KV v2

Même en KV, vous pouvez mettre en place une rotation manuelle avec le versioning de KV v2. Ça ne remplace pas le dynamique, mais ça permet un historique et un rollback.

Ce que les secrets dynamiques ne résolvent pas

Les secrets dynamiques réduisent considérablement les risques, mais ne suppriment pas tout :

Besoin	Reste nécessaire
Authentification du workload	Le workload doit prouver son identité à Vault (K8s auth, OIDC, AppRole…)
Policies strictes	Les permissions Vault doivent être finement configurées
Monitoring et audit	Centraliser et surveiller les logs Vault reste indispensable
Haute disponibilité	Vault devient un SPOF — prévoir cluster HA
Gestion des échecs	Que faire si Vault est down ou si le renouvellement échoue ?

Glissez pour voir

Vault devient central

En adoptant les secrets dynamiques, Vault devient la brique de contrôle centrale. Sa disponibilité et sa sécurité deviennent critiques pour toute votre infrastructure.

À retenir

1. Secret statique : Vault stocke, vous gérez le cycle de vie
2. Secret dynamique : Vault génère, gère le TTL et révoque
3. Lease : identifiant du secret dynamique, permet renouvellement et révocation
4. Dynamic role : nouveau credential à chaque requête (recommandé)
5. Static role : credential existant roté automatiquement (legacy)
6. Traçabilité : simplifiée mais dépend d’une bonne configuration
7. KV reste utile : pour les secrets imposés par des tiers
8. Vault devient central : planifiez HA et stratégie de renouvellement

Prochaines étapes

Database secrets Credentials PostgreSQL/MySQL dynamiques

AWS secrets Credentials IAM temporaires

SSH secrets Certificats SSH signés

Identity broker Vault comme courtier d'identité

×

📖 Voir la documentation →