Chapitre 15. KV approfondi

Objectifs pédagogiques

Configurer un montage KV v2 et articuler réglages de montage et réglages par secret. Exploiter les métadonnées comme inventaire vivant. Lire la structure d'un secret sans ses valeurs. Employer kv patch en connaissant ses deux mécanismes. Conduire une migration v1 vers v2. Énoncer les limites d'usage du moteur.

Prérequis

Chapitre 9 (le socle KV, prolongé ici sans être répété), chapitre 11 (les chemins réels, enrichis d'une troisième famille), chapitre 14 (la configuration de montage).

Cours

15.1 Configurer le montage, puis excepter par secret

Le chapitre 9 réglait la rétention secret par secret. Le montage a son étage propre, qui fixe les défauts du domaine.

[Laboratoire]

vault write secret/config max_versions=8 delete_version_after=4320h cas_required=false
vault read secret/config

L'articulation est celle du chapitre 14 : le montage pose la règle, les métadonnées d'un chemin y dérogent. La dérogation joue dans les deux sens pour la rétention, mais dans un seul pour le check-and-set : exigé au montage il s'impose partout, posé par secret il ne protège que ce secret.

La méthode d'administration en découle. Décider d'abord la politique de domaine, en sachant que chaque version conservée est une copie. Lister ensuite les exceptions et leur raison. Un montage dont la moitié des secrets déroge n'a pas de configuration : il a des habitudes.

15.2 Les métadonnées personnalisées, inventaire vivant

custom_metadata attache à chaque secret des étiquettes non secrètes. C'est l'outil qui transforme un magasin de valeurs en parc géré.

vault kv metadata put \
  -custom-metadata=owner="equipe-billing" \
  -custom-metadata=criticity="haute" \
  -custom-metadata=rotation-due="2026-11-01" \
  secret/billing/prod/payment-api

Trois étiquettes suffisent à changer l'exploitation. Un propriétaire, et le secret orphelin du chapitre 1 devient détectable. Une criticité, pour prioriser revues et incidents. Une échéance de rotation, pour que la rotation des statiques ait au moins une date qui se scanne.

Deux règles d'hygiène s'imposent. Les métadonnées se lisent avec le droit de lecture sur leur famille de chemins : elles sont donc visibles de quiconque inventorie, et n'accueillent ni valeur ni indice. Et elles ne valent que tenues à jour, ce qui en fait un rituel plutôt qu'une intention.

15.3 Lire la structure sans les valeurs

Note de version : depuis la version 1.10, KV v2 expose une troisième famille de chemins, secret/subkeys/<chemin>, qui renvoie la structure d'un secret avec toutes les valeurs remplacées par null.

curl --cacert "$VAULT_CACERT" -H "X-Vault-Token: $(cat ~/.vault-token)" \
  "$VAULT_ADDR/v1/secret/subkeys/billing/prod/db"

L'usage est l'outillage : un script de conformité qui vérifie que chaque secret de base porte bien les champs attendus, un inventaire qui recense les schémas, sans que l'outil n'ait jamais le droit de lire une valeur. C'est du moindre privilège de précision.

Le réflexe du chapitre 11 s'enrichit donc : KV v2 se gouverne sur trois familles de chemins, les valeurs, l'existence et les étiquettes, la structure. Une revue de policies KV vérifie les trois.

15.4 kv patch, en connaissance de mécanisme

Le geste a été présenté au chapitre 9, sa capability au chapitre 11. Reste le mécanisme, car il y en a deux, et le choix se lit dans la commande.

vault kv patch secret/billing/prod/db password=-            # methode par defaut
vault kv patch -method=rw secret/billing/prod/db password=-  # repli explicite

La méthode par défaut émet une vraie requête PATCH : le serveur fusionne, l'appelant n'a besoin que de la capability patch. Il modifie un champ sans jamais avoir le droit de lire les autres, ce qui est la version la plus fine de l'écriture. Le repli lit, fusionne côté client et réécrit sous check-and-set : il exige la lecture et l'écriture, donc expose le secret entier.

La règle de choix est du pur chapitre 11 : la méthode serveur quand la policy peut rester minimale, le repli quand on a de toute façon les droits. La différence porte sur les droits accordés, pas sur la forme.

15.5 Migrer de la version 1 à la version 2

Les installations réelles traînent des montages v1. Deux chemins existent, et le premier est une commande à fenêtre.

[Production]. Opération à fenêtre : montage brièvement indisponible, chemins d'API modifiés

vault kv enable-versioning kv-legacy/

La conversion se fait en place, les données devenant la version 1 de chaque chemin, avec une brève indisponibilité. Mais ce qui fait de cette commande un projet n'est pas l'indisponibilité : c'est le changement d'API. Un montage v1 sert un chemin direct ; converti, il sert le même chemin préfixé de data/. À la seconde de la conversion, toutes les policies écrites sur les chemins v1 cessent de correspondre, et tout client qui parlait l'API v1 reçoit des erreurs.

Le plan s'écrit donc à l'envers : inventaire des policies et des consommateurs, réécriture des policies en trois familles, mise à jour des clients, fenêtre annoncée, conversion, tests avec les refus attendus. L'alternative, quand la fenêtre est impossible : monter un v2 neuf à côté, copier par script, basculer progressivement, puis décommissionner le v1. Plus long, jamais bloquant.

15.6 Les limites d'usage

Trois limites, à connaître avant qu'elles ne s'apprennent en incident.

La taille. Une valeur KV est une entrée de stockage, répliquée par Raft, chargée en mémoire, journalisée en empreinte. Le moteur est fait pour des secrets de quelques kilooctets, pas pour des fichiers. Un blob de plusieurs mégaoctets n'y a pas sa place, et la bonne architecture est celle du chapitre 16 : le gros objet vit ailleurs, chiffré, et Vault ne garde que la clé.

Le débit d'audit. Chaque lecture est une requête auditée. Une application qui relit son secret à chaque transaction fabrique du journal et de la charge pour rien. On lit au démarrage et au renouvellement, pas à la requête.

La fraîcheur. KV ne notifie pas : une valeur changée n'est vue qu'à la prochaine lecture. Les consommateurs se conçoivent avec leur rythme de relecture, et la rotation d'un statique compose avec ce rythme.

15.7 Organiser à plusieurs équipes

La question du chapitre 14 revient avec un visage précis : un montage KV unique à préfixes, ou des montages par domaine ?

Les critères ne changent pas. Des politiques de rétention différentes justifient des montages séparés, la configuration étant par montage. Un cloisonnement de destruction, pour décommissionner le domaine d'une filiale d'un geste, aussi. Tout le reste, le simple chacun chez soi, se fait mieux par préfixes et policies, qui coûtent zéro montage.

Astrea, quatre-vingts personnes, reste sur un montage unique avec ses préfixes par application. Décision consignée, avec son critère de révision : une exigence de rétention divergente, ou une entité juridiquement séparée, auquel cas la discussion deviendrait celle des namespaces Enterprise.

Exemple : la revue trimestrielle KV d'Astrea

Un rituel d'une heure par trimestre, outillé par ce chapitre. Un script sous policy dédiée, qui énumère et lit les métadonnées et la structure mais rien des valeurs, parcourt l'arborescence et produit trois listes.

Les échéances. Tout secret dont la date de rotation est passée ou proche. Deux trouvés, dont la clé du prestataire de paiement, rotation planifiée avec l'équipe propriétaire.

Les orphelins. Tout secret sans propriétaire, ou dont le propriétaire a quitté l'entreprise. Un trouvé, reliquat de test, détruit selon le cycle du chapitre 9.

Les anomalies de structure. Via la troisième famille de chemins, tout secret de base auquel manque un champ attendu. Aucun ce trimestre.

La revue se clôt par la relecture de la configuration de montage et des dérogations : deux dérogations de rétention, toutes deux encore justifiées, la justification re-datée. Une heure, trois listes, zéro valeur lue. L'inventaire du chapitre 1, qui n'existait pas, est devenu un rapport que produit une policy incapable de lire les secrets.

Sécurité : la troisième famille, et les autres

La structure s'accorde comme un droit, pas comme un confort. Les noms de champs disent l'architecture. Accordé large, l'endpoint devient une carte du parc pour un attaquant : il se réserve à l'outillage qui en a besoin.

Les métadonnées sont publiques à l'échelle de leur droit. Ni valeur, ni indice, ni donnée personnelle : des étiquettes d'exploitation, relues par la revue.

La migration v1 vers v2 est un changement de surface d'autorisation. La vieille policy n'accorde plus rien, et une policy réécrite trop vite peut accorder trop. Les tests de migration incluent la grille de refus du chapitre 11.

Les gros objets restent hors de KV. Un blob dans KV est un blob répliqué, snapshoté et chargé en mémoire à chaque lecture : une surface disproportionnée. L'objet se chiffre ailleurs, la clé seule vit dans Vault.

Erreurs fréquentes

Configurer secret par secret ce qui devait l'être au montage. Cinquante dérogations locales et pas de politique : la revue devient impossible (section 15.1).

Glisser une valeur sensible dans les métadonnées. L'ancien mot de passe « pour mémoire » est lisible par tout détenteur du droit d'inventaire, hors du régime des versions et de la destruction (section 15.2).

Accorder la structure avec les métadonnées par habitude. Trois familles, trois droits. La structure se donne à l'outillage, pas à tout lecteur d'inventaire (section 15.3).

Employer le repli de patch sans le savoir. Il exige la lecture : le pipeline qui ne fait que patcher lit en réalité le secret entier (section 15.4).

Convertir un montage v1 sans réécrire les policies. La commande réussit, le montage revient, et plus personne n'est autorisé (section 15.5).

Stocker des fichiers dans KV. Réplication, snapshots et mémoire en souffrent, et la valeur échappe aux bons patterns (section 15.6).

Relire le secret à chaque requête applicative. Du volume d'audit et de la charge pour un secret qui n'a pas changé (section 15.6).

Mise en pratique : trois décisions d'exploitation

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

1. Rédigez la policy complète du script de revue trimestrielle d'Astrea, au moindre privilège strict.
2. Un montage v1 kv-legacy/ sert deux applications en API directe et trois policies. Établissez le plan de migration en place, étape par étape, avec le contenu du test final.
3. L'équipe data veut ranger dans KV des exports chiffrés de 200 Mo parce que c'est sensible. Rédigez le refus argumenté et la contre-proposition d'architecture.

Questions de compréhension

1. Articulez configuration de montage et métadonnées par secret : qui fixe quoi, dans quel sens les dérogations jouent-elles, et quelle exception pour le check-and-set ?
2. Donnez trois étiquettes utiles et le problème du chapitre 1 que chacune attaque, puis les deux règles d'hygiène qui les encadrent.
3. Que renvoie la famille subkeys, depuis quelle version, et quel usage au moindre privilège permet-elle ?
4. Énoncez la règle des trois familles de chemins et ce qu'une revue de policies doit vérifier.
5. Distinguez les deux mécanismes de kv patch, leurs exigences de capabilities, et la règle de choix.
6. Pourquoi la conversion d'un montage v1 est-elle un projet ? Détaillez l'effet qui casse les policies.
7. Donnez les trois limites d'usage de KV et le pattern qui répond à celle des tailles.
8. Quels critères justifient de séparer des montages KV, et pourquoi « un montage par équipe » n'en fait-il pas partie ?

Synthèse

KV en régime réel, c'est un montage configuré, avec sa politique de rétention de domaine et ses dérogations datées, et trois familles de chemins à gouverner : les valeurs, l'existence et les étiquettes d'inventaire, la structure sans les valeurs apparue en 1.10. kv patch se choisit par mécanisme, celui du serveur modifiant sans lire. La migration v1 vers v2 se planifie à l'envers, parce que la conversion change les chemins réels et donc toute l'autorisation. Les limites du moteur dessinent son bon usage : des valeurs de quelques kilooctets lues au rythme des tokens, jamais des fichiers ni du trafic. Les gros objets se chiffrent ailleurs, avec une clé que Vault garde, ce qui appelle le moteur suivant.