Chapitre 14. Anatomie d'un moteur de secrets

Objectifs pédagogiques

Décrire le contrat commun des moteurs et le cycle de vie d'un montage. Expliquer la hiérarchie des durées à trois étages. Définir un bail et agir dessus. Situer le seal wrap de l'édition Enterprise. Organiser les montages d'une installation.

Prérequis

Chapitre 4 (table des montages et vues de stockage), chapitre 9 (un premier moteur vécu), chapitre 12 (la logique des durées, transposée ici des tokens aux secrets).

Cours

14.1 Le contrat commun

Un moteur de secrets est un composant monté sous un chemin, qui traduit les opérations de l'API en logique de service : stocker et versionner pour KV, chiffrer pour Transit, signer des certificats pour PKI, créer des comptes pour Database.

Tout ce que les parties précédentes ont établi s'applique uniformément. Le montage a une vue de stockage isolée, ses données vivant sous un préfixe interne propre. Ses chemins se gouvernent par des policies ordinaires : il n'y a pas d'autorisations spéciales, seulement des chemins de plus. Ses opérations passent par le même cycle de requête et le même audit. Apprendre un moteur, c'est donc apprendre ses chemins et sa logique.

[Laboratoire]

vault secrets list -detailed

Trois colonnes méritent attention. Le type et le chemin : un même type peut être monté plusieurs fois sous des chemins différents, deux KV ou deux PKI étant des instances indépendantes. L'accessor du montage, identifiant stable que la couche Identity utilisait déjà pour les méthodes d'authentification. Et les durées, objet de la section 14.4.

14.2 Le cycle de vie d'un montage

Quatre verbes, dont un dangereux.

Activer : vault secrets enable -path=<chemin> <type>. Le chemin est un choix définitif de fait, puisque policies, clients et scripts pointeront dessus.

Régler : vault secrets tune modifie les paramètres d'un montage vivant, dont les durées de la section 14.4. Des options avancées existent, que ce cours signale sans les recommander : exclure des champs du masquage de l'audit se paie en secrets lisibles dans les journaux.

Déplacer : vault secrets move réinstalle un montage ailleurs, données comprises. Le montage est indisponible pendant l'opération, et surtout rien ne réécrit les policies ni les configurations clientes. Un déplacement sans plan de mise à jour est une panne d'autorisation instantanée.

Détruire : vault secrets disable <chemin> détruit la vue de stockage, secrets, versions et configuration compris, et révoque ce qui en dépendait. L'opération efface le domaine ; elle ne le démonte pas provisoirement. L'opération est légitime, et se traite comme une destruction : inventaire des dépendances, sauvegarde si besoin, décision écrite.

14.3 Les baux : le temps attaché aux secrets

Quand un moteur produit un secret, il peut l'assortir d'un bail : un objet de gestion portant un identifiant, une durée et un caractère renouvelable ou non.

Le bail matérialise un contrat : ce secret vous est prêté pour ce temps. À l'échéance, le gestionnaire d'expiration exécute la logique de révocation du moteur, ce qui pour un credential de base de données signifie supprimer le compte. C'est la différence entre prêter et donner. Un secret sous bail reste sous contrôle de Vault après sa remise : révocable à distance, expirant seul. Un secret statique, une fois lu, est donné pour toujours.

Quelques précisions cadrent la notion. KV ne produit pas de baux : lire un secret remet une copie, sans contrat de retour. Les tokens relèvent de la même machinerie : le gestionnaire d'expiration du chapitre 12 et celui-ci ne font qu'un. Et les baux s'administrent par une famille de chemins système.

vault lease lookup <lease_id>        # que reste-t-il a ce bail
vault lease renew <lease_id>         # prolonger, dans la limite du plafond
vault lease revoke <lease_id>        # revoquer maintenant : le moteur nettoie

La forme de crise s'encadre comme operator seal l'a été. [Production]. Commande dangereuse : révocation de masse

vault lease revoke -prefix database/

Elle éteint tous les baux d'un sous-arbre : c'est le bouton d'urgence par domaine, quand une base est compromise et qu'on coupe tout ce que Vault y avait ouvert. Son coût est celui du bouton : tout consommateur légitime tombe avec l'attaquant. On connaît la commande, on ne la découvre pas en incident.

14.4 Les durées, à trois étages

Chaque montage porte deux réglages : default_lease_ttl, la durée appliquée quand rien n'est précisé, et max_lease_ttl, le plafond que rien ne franchit sur ce montage.

Les valeurs héritent en cascade. Les défauts système, 768 heures pour l'un et l'autre. Le montage, qui les remplace par tune. Le rôle ou la requête, qui peut réduire encore, jamais dépasser. Le système propose, le montage encadre, le rôle précise.

L'encadrement est dur, et son échec est muet : demander plus que le plafond ne provoque pas d'erreur mais un écrêtage silencieux. C'est la source du piège le plus célèbre du chapitre 17 : une autorité racine générée pour dix ans sur un montage laissé aux défauts sera émise pour trente-deux jours, sans un mot. Le réflexe s'installe ici : avant de créer un objet long, régler le montage.

[Laboratoire]

vault secrets tune -max-lease-ttl=87600h pki-root
vault read sys/mounts/pki-root/tune

Le réflexe inverse vaut autant. Un plafond généreux posé pour être tranquille transforme la défense en passoire : le plafond de montage est la borne que plus personne ne pourra desserrer en aval.

14.5 Enterprise : le seal wrap

L'édition Enterprise offre au montage une protection supplémentaire, activable à la création : le seal wrap fait chiffrer les valeurs les plus critiques par le mécanisme de scellement lui-même, en plus de la barrière. L'intérêt est double : un chiffrement dont la clé vit hors du serveur, et surtout la possibilité d'inscrire ces données dans le périmètre d'un module certifié, ce qui est souvent le motif réel. En édition Community, la barrière est la protection, et elle est solide.

14.6 Organiser les montages

Trois critères décident du découpage.

Le réglage : deux usages qui exigent des durées ou des options différentes appellent deux montages. C'est tout le cas PKI, une racine longue et un intermédiaire moyen, donc deux plafonds.

Le rayon d'explosion : le montage est l'unité de destruction et de révocation de masse. Regrouper des domaines sans rapport, c'est les condamner à tomber ensemble.

La lisibilité des droits : les policies se lisent mieux quand le premier segment du chemin dit déjà le domaine.

L'anti-modèle est symétrique : multiplier les montages par réflexe, un par équipe ou par application, recrée l'étalement du chapitre 1 dans Vault même. La règle du cours est un montage par nature de service et par régime de réglage, des préfixes et des policies pour le reste. Les organisations dont le cloisonnement doit aller jusqu'à l'administration déléguée disposent des namespaces en édition Enterprise, que le chapitre 27 situera.

Exemple : la table des montages cible d'Astrea

L'architecte pose la table complète avant de construire, versionnée au même dépôt que les policies.

Montage	Type	Régime de durées	Justification
secret/	kv-v2	sans objet, pas de baux	les statiques, réglés par secret/config
transit/	transit	sans objet, clés à versions	le service de chiffrement, clé billing-data
pki-root/	pki	plafond dix ans, réglé avant génération	la racine, la leçon de 14.4 appliquée d'avance
pki-int/	pki	plafond cinq ans, feuilles à 72 h par le rôle	l'intermédiaire, trois étages de durées
database/	database	plafond court, défini au chapitre 19	les credentials PostgreSQL
ssh/	ssh	idem	les certificats SSH du chapitre 19

Six montages, six natures de service, aucun doublon d'équipe ni d'application. La carte tient sur un écran, et c'est un critère.

Sécurité : les montages comme pouvoir

sys/mounts est un chemin de pouvoir. Qui peut activer un montage étend la surface, chaque moteur apportant ses chemins et parfois ses appels sortants. Qui peut le régler peut allonger toutes les durées d'un domaine. Qui peut le désactiver détruit le domaine.

Le plafond de montage est une défense de dernier ressort. Tout ce qui se crée dessous pourra réduire les durées, jamais les étendre. Le régler au plus juste borne d'avance les erreurs de tous les rôles futurs.

Les baux se comptent. Un stock qui gonfle sans expirer signale des renouvellements oubliés ou une fuite de consommation. L'ordre de grandeur attendu par moteur fait partie du dossier d'architecture.

La révocation de masse se prépare à froid. Savoir quel préfixe couper pour quel incident, ce que la coupure emporte de légitime, et comment le service se rétablit : c'est un exercice de table avant d'être une commande.

Erreurs fréquentes

Désactiver un montage pour nettoyer. C'est détruire : données, versions, configuration, baux. L'inventaire des dépendances précède toujours (section 14.2).

Oublier le plafond avant les objets longs. L'écrêtage est silencieux : la racine dix ans devient trente-deux jours sans erreur. Le réglage précède la génération et se vérifie par relecture (section 14.4).

Déplacer un montage sans plan. L'opération ne réécrit ni policies ni clients : tout ce qui pointait l'ancien chemin échoue à la seconde (section 14.2).

Confondre les valeurs KV et des baux. Le statique n'a pas de contrat de retour : c'est sa définition, et la motivation de la partie VI (section 14.3).

Découvrir la révocation de masse en incident. Jouée pour la première fois sous pression, elle surprend par son rayon. Elle se répète en laboratoire, périmètre chronométré (section 14.3).

Un montage par équipe. L'étalement reconstitué dans l'outil qui devait le résoudre. Le découpage suit la nature du service, pas l'organigramme (section 14.6).

Mise en pratique : lire, régler, décider

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

1. Une sortie de vault secrets list -detailed montre un montage kv-old/ de type kv version 1, description vide, durées aux défauts système, et plus aucune policy ne le mentionne. Proposez la procédure complète de décommission, dans l'ordre, avec ses vérifications.
2. On vous demande un montage pour des credentials d'API tiers dont le fournisseur impose une rotation sous vingt-quatre heures. Donnez la commande d'activation et le réglage des deux durées, avec justification.
3. Classez du plus au moins dangereux, en justifiant : secrets disable database/, lease revoke -prefix database/creds/billing-app/, secrets tune -max-lease-ttl=8760h database/.

Questions de compréhension

1. Énoncez le contrat commun des moteurs et les trois acquis antérieurs qui s'appliquent uniformément.
2. Que détruit exactement la désactivation d'un montage, et quelles précautions impose-t-elle ?
3. Pourquoi le déplacement d'un montage est-il une opération à plan, et que ne fait-il pas ?
4. Définissez un bail : ce qu'il porte, ce qu'il matérialise, ce que fait le gestionnaire d'expiration à l'échéance.
5. Pourquoi les valeurs KV n'ont-elles pas de bail, et quelle conséquence de conception cela illustre-t-il ?
6. Restituez la hiérarchie des durées et le comportement d'écrêtage, avec le piège du chapitre 17 qu'il prépare.
7. Quand la révocation par préfixe est-elle légitime, et quel est son coût assumé ?
8. Qu'apporte le seal wrap, dans quelle édition, et quel motif le fait souvent choisir ?
9. Donnez les trois critères de découpage des montages et l'anti-modèle qu'ils écartent.

Synthèse

Tout moteur est un montage : vue de stockage isolée, chemins gouvernés par les policies ordinaires, même cycle de requête. Son cycle de vie tient en quatre verbes dont un destructeur. Ses durées s'étagent, le système proposant, le montage encadrant et le rôle précisant, avec un écrêtage silencieux qui piège les objets longs. Le bail, formalisé ici, est le contrat de prêt qui distingue le dynamique du statique : un secret sous bail expire et se révoque, unitairement ou par préfixe entier. Le seal wrap ajoute, en édition Enterprise, l'enveloppe du seal pour les dossiers de conformité. Et les montages s'organisent par nature de service et régime de réglage.