Chapitre 18. Le modèle dynamique

Objectifs pédagogiques

Opposer stock et flux et énoncer les quatre propriétés du secret dynamique. Décrire la mécanique générique d'un moteur. Dérouler le cycle de vie sous bail et analyser le comportement pendant une panne. Gouverner le compte racine du moteur. Distinguer rôle dynamique et rôle statique géré, et appliquer la grille de décision.

Prérequis

Chapitre 14 (les baux, que ce chapitre fait vivre), chapitre 12 (durées et révocation côté tokens, même modèle), chapitre 9 (les limites du statique, dont ce chapitre est la réponse).

Cours

18.1 Du stock au flux

Même le meilleur statique ne corrige pas trois défauts. Un mot de passe dans KV reste partagé entre toutes les instances qui le lisent : l'audit dit qui a lu, pas qui a agi sur la base. Il reste durable tant qu'une rotation manuelle ne l'a pas changé, et le chapitre 9 a montré ce que coûte une rotation coordonnée. Il reste irrattrapable une fois lu : la copie donnée ne se reprend pas, et révoquer un token ne révoque pas ce que le token a lu.

Le modèle dynamique attaque les trois d'un coup en changeant la nature de l'objet : le secret n'est plus une valeur conservée, c'est un acte de création. À la demande, Vault fabrique un compte aux identifiants uniques, l'assortit d'un bail court, et le détruit à l'échéance.

Quatre propriétés en découlent. Unique : chaque demandeur, chaque instance, chaque exécution reçoit le sien, et l'imputabilité descend jusqu'au système cible. Court : la fenêtre de compromission est la durée du bail, non le temps écoulé depuis la dernière rotation. Révocable pour de vrai : révoquer le bail détruit le compte côté cible, et c'est la première fois du cursus qu'une révocation reprend un secret déjà remis. Sans rotation : le problème central du chapitre 9 disparaît par construction, puisqu'on ne fait pas tourner ce qui meurt seul.

18.2 La fabrique de comptes

La mécanique compte trois pièces, que chaque moteur déclinera.

Un compte racine. Pour créer des comptes sur une cible, Vault doit y détenir un accès privilégié : un compte PostgreSQL capable de créer des rôles, une clé d'API cloud capable de créer des identités. Il est configuré une fois, et la section 18.4 traitera le paradoxe qu'il incarne.

Des instructions de création et de révocation. Le moteur sait quoi exécuter sur la cible pour fabriquer un compte, et pour le détruire. Sur le moteur Database, ce sont littéralement des ordres SQL paramétrés où Vault injecte le nom, le mot de passe et l'échéance qu'il vient de générer. Sur les moteurs cloud, ce sont des appels d'API. La conséquence est majeure : les privilèges du compte créé sont écrits dans le rôle. C'est le moindre privilège déplacé jusque dans la base : un rôle qui accorde la lecture fabrique des comptes qui ne savent que lire, quels que soient les droits Vault du demandeur.

Un nom unique par émission. Les identifiants générés encodent le rôle et l'origine, de sorte qu'un compte se lit dans les journaux de la base. Le lien entre une ligne de journal côté cible et une identité côté Vault passe par le bail et l'audit : la chaîne d'imputabilité de la partie IV gagne son dernier maillon.

18.3 Le cycle de vie, vécu

Le chapitre 14 a défini le bail ; voici sa vie du point de vue de l'application.

La demande : une lecture sur le chemin de credentials du rôle. La réponse contient les identifiants, un identifiant de bail, une durée, un caractère renouvelable.

L'usage : l'application se connecte à la cible avec les identifiants. Vault n'est plus dans la boucle. Le compte existe sur la cible, le bail existe dans Vault, les deux liés.

Le renouvellement : tant que l'application vit et que le plafond n'est pas atteint, le bail se prolonge. Le rythme naturel est celui du token : même boucle, mêmes horizons, et le chapitre 40 montrera l'agent orchestrer les deux.

La fin : à l'expiration ou sur révocation, le gestionnaire d'expiration exécute les instructions de révocation et le compte disparaît de la cible. Si l'application meurt sans prévenir, son bail expire seul : pas de compte fantôme, et le cas nominal se nettoie sans opérateur.

Reste le cas non nominal, à raisonner froidement. Que se passe-t-il quand Vault est indisponible ? Les credentials déjà émis continuent de fonctionner, la cible ne consultant pas Vault : une panne courte est invisible pour les applications en régime établi. Mais rien de neuf ne s'émet et rien ne se renouvelle. Les baux qui atteignent leur échéance pendant la panne expirent, et selon que la cible applique l'échéance elle-même ou attend l'ordre de révocation, le compte cesse de fonctionner ou survit jusqu'au retour de Vault, qui rattrape alors ses révocations.

La conclusion d'architecture est celle du chapitre 16, en plus aigu : le dynamique fait de Vault une dépendance de démarrage et de renouvellement pour toute la production. C'est l'argument chiffré du dossier haute disponibilité, et un paramètre de conception applicative. Une application qui obtient ses credentials au démarrage et les renouvelle avec marge traverse une panne courte ; une application qui redemande à chaque besoin s'arrête net.

18.4 Le compte racine du moteur

Le paradoxe mérite d'être regardé en face : pour supprimer les secrets partagés et durables, Vault détient un secret partagé avec la cible et durable. Trois disciplines le domestiquent.

Le moindre privilège, côté cible. Le compte que Vault utilise n'est pas le superutilisateur, mais un compte dédié créé pour l'occasion, avec exactement les droits qu'exigent les instructions du moteur : créer des rôles, leur accorder les droits prévus, les supprimer. Si le moteur est compromis, l'attaquant fabrique des comptes du périmètre des rôles ; il ne devient pas administrateur de la base.

La rotation par Vault lui-même. La plupart des moteurs exposent une opération de rotation du compte racine : Vault change le mot de passe de son propre compte sur la cible et ne le dit à personne. Après elle, plus aucun humain ne connaît ce mot de passe. La valeur saisie à la configuration, qui a transité par un terminal et un historique, est morte, et le secret n'existe plus que dans la barrière. C'est un geste d'hygiène standard juste après la configuration d'un moteur, et il est irréversible pour l'opérateur. C'est voulu, et cela impose la troisième discipline.

Un compte de secours hors Vault. Il reste indispensable de pouvoir administrer la cible quand Vault est en panne ou que le moteur est mal configuré. Ce compte, sous scellé procédural, n'est jamais géré par Vault, précisément parce qu'il sert quand Vault ne peut pas servir. La règle fait miroir à celle du chapitre 5 : le moyen de réparer le système ne doit pas dépendre du système.

18.5 Dynamique, statique géré, statique : la grille

Le dynamique ne convient pas partout, et le reconnaître fait partie du modèle. Deux limites structurelles. La cible doit savoir créer des comptes : un partenaire qui remet une clé d'API unique et immuable ne se dynamise pas. Et le consommateur doit savoir vivre avec des identifiants changeants : un progiciel qui lit sa configuration une fois au démarrage s'accommode mal d'un compte qui meurt toutes les heures.

Pour la seconde limite, les moteurs offrent un intermédiaire : le rôle statique géré. Le compte existe, unique et permanent, créé par l'administrateur de la cible, mais Vault en gouverne le mot de passe : rotation automatique, distribution de la valeur courante aux seuls autorisés. Le compte ne meurt pas, mais son secret tourne sans humain. C'est la moitié du bénéfice, pour les consommateurs qui ne peuvent pas mieux.

La grille se lit alors en cascade, et se consigne par système cible. La cible sait-elle créer des comptes, et le consommateur suivre ? Dynamique, la réponse par défaut. Le consommateur ne suit pas, mais la cible accepte un changement de mot de passe ? Statique géré. Ni l'un ni l'autre ? Statique en KV, avec tout le chapitre 9 et la lucidité du chapitre 2 : c'est un risque résiduel accepté, daté, revu.

Exemple : la grille appliquée à billing

La décision consignée par l'architecte, un tableau de trois lignes au dossier.

Besoin	Régime	Paramètres	Raison
API billing	dynamique	bail 1 h, plafond 24 h	PostgreSQL sait créer des rôles, l'application sait relire au rythme de son token
Traitement nocturne de rapprochement	statique géré	rotation nocturne après la fenêtre	outil hérité, configuration chargée au lancement, connexions de quatre heures
Clé du prestataire de paiement	statique en KV	rotation trimestrielle en métadonnée	valeur émise par un tiers, immuable côté tiers

Trois besoins, trois régimes, zéro dogme. La grille décide, le dossier garde la trace, et le risque résiduel de la troisième ligne est accepté et daté.

Sécurité : ce que le modèle déplace

Le moteur devient une cible de choix. Qui contrôle la configuration d'un moteur dynamique contrôle une fabrique de comptes sur la cible. Ces chemins rejoignent la liste des chemins de pouvoir : écriture réservée, alarmée, revue.

Le compte racine est le secret le plus lourd du système. Moindre privilège côté cible, rotation dès la mise en service, secours hors Vault : les trois disciplines forment un bloc. En appliquer deux sur trois laisse un trou, et une rotation sans compte de secours est un enfermement dehors programmé.

La révocation peut échouer. Si la cible est injoignable à l'échéance, Vault retente, mais un bail peut rester coincé et le compte orphelin côté cible. La supervision des baux et un inventaire périodique côté cible ferment la boucle. La révocation forcée existe pour abandonner un bail insistant, en sachant qu'elle abandonne aussi la garantie de nettoyage : l'orphelin devient certain, à traiter à la main.

La charge se déplace vers la cible. Créer et détruire des comptes n'est pas gratuit pour une base. Des durées très courtes sur une flotte nombreuse se dimensionnent, et le bail d'une heure de billing est un choix mesuré : plus court que le besoin, c'est du churn sans gain.

Erreurs fréquentes

Tourner le compte racine sans compte de secours. La rotation réussit, et le jour où Vault est en panne, plus personne ne sait administrer la base. Le secours se vérifie avant (section 18.4).

Le superutilisateur comme compte de moteur. La compromission du moteur devient celle de la cible entière. Le compte dédié a le périmètre de ses instructions, rien de plus (section 18.4).

Des privilèges larges dans les instructions de création. Le moindre privilège s'est arrêté à la porte de la base. Les instructions du rôle sont la policy côté cible et se relisent comme du HCL (section 18.2).

Confondre statique géré et dynamique. Le statique géré tourne un mot de passe, il ne fabrique rien : deux chemins, deux modèles (section 18.5).

Des plafonds longs pour éviter le churn. La fenêtre de compromission redevient un mois, et le dynamique n'a plus de dynamique que le nom. Le plafond se justifie par le besoin, le churn se traite par le renouvellement (sections 18.3, 18.5).

Redemander des credentials à chaque requête. Charge sur Vault et la base, baux par milliers. On obtient au démarrage, on renouvelle avec marge, on relit à l'expiration (section 18.3).

Mise en pratique : la grille, le compte racine, la panne

Sur papier ; réponses commentées en fin de partie.

1. Classez ces quatre besoins dans la grille, avec une phrase de justification chacun : un exporteur de métriques qui lit une base en continu ; une clé d'API d'un service d'envoi de courriels ; un ordonnanceur hérité qui charge sa configuration au démarrage et tourne des semaines ; les accès des développeurs à la base de préproduction.
2. Rédigez le runbook de mise en service du compte racine d'un moteur Database, de la création du compte côté base jusqu'à l'état final, en plaçant la rotation et le compte de secours au bon endroit.
3. Vault est indisponible quarante minutes. Analysez l'impact sur une instance billing en régime établi dont le bail d'une heure est renouvelé aux deux tiers, sur une instance qui démarre pendant la panne, et sur le traitement nocturne en statique géré dont la rotation tombait dans la fenêtre.

Questions de compréhension

1. Énoncez les trois défauts du statique que même KV bien géré ne corrige pas, et les quatre propriétés qui y répondent.
2. Décrivez les trois pièces de la fabrique, et où vivent les privilèges du compte créé.
3. Pourquoi la révocation dynamique est-elle la première vraie révocation du cursus ?
4. Déroulez le cycle de vie d'un credential du point de vue de l'application, et le rythme naturel de son renouvellement.
5. Analysez le comportement pendant une indisponibilité de Vault : ce qui continue, ce qui s'arrête, la conclusion d'architecture.
6. Justifiez les trois disciplines du compte racine, et expliquez ce que la rotation rend définitivement impossible.
7. Qu'est-ce qu'un rôle statique géré, quel problème résout-il, et qu'est-ce qu'il ne résout pas ?
8. Restituez la grille de décision et donnez un exemple de chaque régime.

Synthèse

Le modèle dynamique change la nature du secret : non plus une valeur conservée mais un acte de création. Un compte unique par demandeur, court, révocable pour de vrai, mort tout seul, et dont les privilèges sont écrits dans le rôle jusque dans la base. La mécanique est une fabrique : un compte racine à trois disciplines, des instructions qui sont la policy côté cible, des baux qui vivent au rythme des tokens et se nettoient sans opérateur. Le modèle déplace les risques plutôt qu'il ne les efface : Vault devient dépendance de démarrage et de renouvellement, le moteur une cible de choix, la révocation un mécanisme qui peut échouer. Et il ne s'impose pas partout : la grille se décide par système et se consigne.