Après avoir acquis dans la première partie une vue d’ensemble solide de l’écosystème des Secrets Engines, nous allons à présent plonger dans le quotidien de tout cluster Vault. La Key / Value (KV) Secrets Engine constitue le cheval de trait pour toutes les situations où des secrets doivent être stockés de manière sécurisée, versionnés, puis récupérés de manière ciblée ultérieurement.
Bien que Vault soit surtout reconnu pour ses capacités dynamiques, toute infrastructure réelle comporte un grand nombre de valeurs statiques - des clés API de services SaaS externes aux mots de passe de comptes de service sans date d’expiration, en passant par des bundles de certificats pour systèmes legacy. Sans un stockage Key/Value robuste, ces données continueraient à circuler de manière incontrôlée dans des fichiers texte, des dépôts Git, des systèmes CI, voire dans des tableurs Excel. La Key/Value Secrets Engine empêche précisément cela.
Dans ce sous-chapitre, nous allons examiner de manière pratique
- comment activer une telle Key/Value Secrets Engine,
- quelles réflexions influencent le choix du chemin de montage, et
- comment concevoir une structure hiérarchique qui restera compréhensible même dans cinq ans.
Dans les sous-chapitres suivants à partir de la partie 2b, nous aborderons différents aspects de la Key/Value Secrets Engine - y compris les différences entre les deux variantes du KV-Store, la mise à niveau de l’ancienne vers la nouvelle version, la manière d’écrire et de lire les données, la gestion des métadonnées, ainsi que la versionnage, la suppression et la restauration ciblée des secrets stockés.
Qu’est-ce que la Key / Value Secrets Engine ?
La Key/Value Secrets Engine (ou simplement KV‑Engine) répond à une question simple mais omniprésente :
Où stocker des secrets immuables de manière à les protéger des regards indiscrets, les consigner de façon traçable et les rendre facilement accessibles aux pipelines d’intégration, aux utilisateurs humains et aux applications ?
D’un point de vue technique, il s’agit d’un Key‑Value‑Store transactionnel chiffré, qui crypte toutes les données de manière transparente en AES 256 bits avant de les enregistrer dans le backend de stockage.
Chaque opération de lecture ou d’écriture est consignée de manière exhaustive par le sous-système d’audit de Vault, ce qui permet de retracer avec précision qui a accédé à quel chemin et à quel moment.
Pour les équipes ayant jusqu’ici utilisé des solutions Cloud KMS ou des Parameter Stores, la KV‑Engine constitue souvent le premier point de contact avec Vault, car elle offre un modèle de données familier tout en apportant des fonctions de sécurité et d’automatisation nettement étendues.
Deux versions, deux philosophies
Un détail qui provoque régulièrement de la confusion : il existe deux variantes de cette Engine.
- Version 1 (kv) : La variante classique non versionnée
- Version 2 (kv-v2) : La variante moderne avec gestion des versions
La version 1, appelée simplement « kv » en interne, ne conserve qu’une seule version courante par entrée. Toute écrasement supprime irréversiblement les anciennes données. Ce comportement était suffisant à l’époque des débuts de Vault, mais ne répond plus aux exigences de conformité actuelles.
La version 2, configurable sous le nom kv‑v2 ou via le paramètre ‑version=2, maintient quant à elle un historique complet par entrée. Toute modification d’une paire clé/valeur crée une nouvelle révision, récupérable ou restaurable de manière ciblée. Il est également possible d’effectuer des suppressions logiques (soft-deletes) avec une période de rétention définie avant qu’une valeur ne soit définitivement supprimée.
Dans les installations modernes, seule la variante v2 devrait donc être utilisée. La v1 ne subsiste que dans les cas où des workloads legacy dépendent d’une API stable et ne peuvent être migrés à court terme.
Au-delà de la seule gestion des versions, v2 propose d’autres fonctionnalités : chaque entrée peut par exemple être protégée par un index Check‑and‑Set optionnel, qui empêche les Blind Writes. Il est également possible de limiter côté serveur le nombre maximal de révisions conservées, afin de maîtriser la consommation de stockage et le trafic de réplication.
Pour l’examen de certification, il est important de savoir qu’une mise à niveau de v1 vers v2 ne s’effectue pas automatiquement. Le processus de migration doit être déclenché manuellement et nécessite des ACL appropriées, voire un plan en plusieurs étapes si des dizaines d’applications sont concernées. Les chemins d’API changent également, ce qui signifie que les scripts et applications doivent être adaptés lors d’une migration de v1 vers v2.
Important en pratique : dans toute nouvelle implémentation, seule la version 2 devrait être utilisée. La version 1 est obsolète et ne s’emploie plus que dans des scénarios legacy spécifiques.
Modes d’accès et intégration
Comme pour tous les composants de Vault, trois principaux modes d’interaction sont disponibles.
- UI : Pour une utilisation interactive et une visualisation rapide, idéale pour les tâches ad hoc dans les environnements de développement ou de démonstration. Ce mode n’étant pas adapté aux environnements de production, nous n’approfondirons pas l’UI dans cette série d’articles.
- CLI : Pour les administrateurs et le scripting. Le CLI est l’équivalent en production des clics dans l’UI. Nos exemples de code utilisent le CLI.
- API : Pour l’automatisation et l’intégration dans les pipelines et les applications.
L’utilisation de l’API via Infrastructure-as-Code constitue la norme en environnement de production. Un job de build peut par exemple, juste avant le déploiement, demander un token fraîchement généré, puis récupérer le secret souhaité dans le chemin KV apps/payment/prod/api_key via une simple requête GET.
Pour les workloads comme les applications, le Vault Agent est recommandé : il met les données à disposition dans des fichiers temporaires et renouvelle automatiquement les tokens d’accès de l’application. Grâce à cette flexibilité, la KV‑Engine s’adapte à pratiquement tous les workflows, sans compromettre les objectifs de sécurité fondamentaux.
La sécurité comme principe de conception
Toutes les données dans la KV‑Engine sont chiffrées avant d’être stockées. Ainsi, peu importe pour les auditeurs ou les équipes d’exploitation que le backend physique soit un système de fichiers local, un cluster Consul (standard jusqu’il y a quelques années) ou le backend Raft intégré (standard actuel). Même un stockage compromis ne peut en aucun cas reconstituer les données en clair.
Les droits d’accès sont gérés par Vault via son système de politiques. Des chemins individuels peuvent être protégés par des règles de politique basées sur des autorisations comme read, create, update ou delete. Un scénario typique en production prévoit que les développeurs disposent de droits en lecture sur un chemin tel que apps/*/prod, tandis que seul l’équipe d’exploitation peut y écrire.
Grâce à l’attribution de capacités spécifiques comme list, il est possible d’empêcher des utilisateurs curieux de découvrir l’existence de chemins enfants.
En tant que couche de sécurité supplémentaire, on peut recourir aux Token Tiers ou aux Control Groups, par exemple pour soumettre des actions particulièrement sensibles à une approbation multifactorielle.
Activation pratique
L’activation d’une KV‑Engine s’effectue, comme déjà montré dans la partie 1, via la commande vault secrets enable <engine>.
Une fois le point de montage défini, celui‑ci est considéré comme un espace de noms - totalement isolé des autres Engines. Gardez à l’esprit qu’un renommage ultérieur n’est possible qu’avec vault secrets move et peut nécessiter des adaptations complexes des policies.
Activer la version 1
# Activation standard de KV v1 $ vault secrets enable kv Success! Enabled the kv secrets engine at: kv/
# Activation sur un chemin personnalisé $ vault secrets enable -path=legacy-secrets kv Success! Enabled the kv secrets engine at: legacy-secrets/
Activer la version 2
# Méthode 1 : Spécification explicite de kv-v2 $ vault secrets enable kv-v2 Success! Enabled the kv-v2 secrets engine at: kv-v2/ # Méthode 2 : Version en paramètre \$ vault secrets enable -path=secrets -version=2 kv Success! Enabled the kv-v2 secrets engine at: secrets/
Conseils professionnels issus de la pratique
1. Chaque point de montage devrait immédiatement recevoir une description, afin que les collègues sachent encore dans six mois à quoi il servait.
2. Il est judicieux de définir l’option max_versions sur les points de montage v2 en production dès que l’on connaît le nombre de révisions réellement nécessaires. Dans les secteurs réglementés, où une conservation sur dix ans est requise, la valeur devra être calculée en conséquence.
3. Je recommande de régler le paramètre cas_required sur true afin d’activer le mécanisme Check-and-Set et d’exclure les écrasements parallèles accidentels. Cela implique que toute opération d’écriture sur un secret (c’est-à-dire create, update ou patch) doit également contenir le paramètre cas. Le paramètre cas agit comme contrôle de version : une opération d’écriture ne réussit que si la valeur cas correspond effectivement à la version actuelle du secret. Ainsi, vous gardez le contrôle sur les écritures concurrentes sur les secrets.
Détection de version
Dans les grandes infrastructures, la question se pose souvent de savoir quels points de montage utilisent déjà la KV‑Engine v2. La commande suivante fournit la réponse dans la colonne « Options ».
$ vault secrets list --detailed Path Type Accessor Description Options ---- ---- -------- ----------- ------- cubbyhole/ cubbyhole cubbyhole_abc123 [...] map[] kv/ kv kv_def456 [...] map[] secrets/ kv kv_ghi789 [...] map[version:2]
Oui, vous avez raison : il faut le savoir.
Si l’entrée version:2 est absente dans map[], il s’agit d’une ancienne instance v1.
Dans les scripts d’automatisation, il est recommandé d’analyser cette sortie de manière exploitable par machine à la recherche de version:2, et non de se baser uniquement sur le nom du chemin. En effet, non seulement le nom du chemin (point de montage) d’une KV‑Engine est librement définissable, mais un utilisateur peut très bien nommer un point de montage v1 kv‑v2.
Concept de chemin et isolation
Chaque KV‑Engine activée constitue un espace de noms propre. Cela signifie :
- Sensibilité à la casse : Les chemins kv/ et KV/ sont différents et totalement indépendants, car Vault distingue les majuscules des minuscules.
- Pas de superpositions : Un montage sur secrets/ empêche les montages supplémentaires sur des chemins enfants comme secrets/sub/. Cela permet d’éviter que deux équipes alimentent par erreur les mêmes répertoires, par exemple en cas de malentendus sur les namespaces attribués.
- Isolation complète : En coulisse, chaque Engine reçoit un chemin UUID généré aléatoirement, qui fonctionne comme un chroot. Même si un montage était compromis, il ne pourrait pas accéder aux données des autres Engines.
Structuration des Secrets
Une convention de nommage claire permet des chemins d’accès courts, des responsabilités bien définies et, au final, moins de demandes de support. Un modèle fréquemment utilisé est »//<secret‑group>/«. En pratique, cela pourrait ressembler à ceci :
apps/
└── aws/
├── prod/
│ ├── user: dbadmin
│ ├── password: P@ssw0rd
│ └── api_key: b93md83mdmapw
└── dev/
├── cert: -----BEGIN CERTIFICATE-----
└── key: -----BEGIN PRIVATE KEY-----
Le répertoire apps/aws/ créé ici sert uniquement de conteneur ; il ne contient aucun secret. Seuls les nœuds les plus bas stockent les paires clé-valeur réelles.
L’avantage de cette hiérarchie réside dans la délégation simple des droits. Une équipe de développement pourrait obtenir un droit de read sur tous les chemins contenant dev, tandis que l’équipe d’exploitation conserve les droits d’écriture globaux pour la production à l’intérieur du namespace attribué (les namespaces sont des instances Vault virtuelles et isolées dans Vault Enterprise).
Modèle d’autorisations
Pour travailler avec la KV Engine, cinq autorisations différentes, appelées Capabilities, sont nécessaires :
- create : Créer de nouveaux secrets (écrase ceux existants en v1)
- update : Modifier des secrets existants (utile uniquement en v2)
- read : Lire des secrets (renvoyés en clair)
- delete : Supprimer des secrets, en mode soft ou hard
- list : Lister les secrets disponibles dans un chemin (uniquement les clés, pas les valeurs)
Ces Capabilities sont attribuées via des policies – un sujet que nous approfondirons dans un article ultérieur. En bref : les policies combinent ces droits et les associent à des Token Roles. Vous pouvez ainsi autoriser un système CI à écrire sur des chemins comme apps/build durant la phase de build, mais uniquement à lire apps//prod lors du job de release.
Perspectives
Dans cet article, nous avons découvert les bases de la Key/Value Secrets Engine et compris les différences importantes entre la version 1 et la version 2.
Dans la prochaine partie, nous approfondirons l’utilisation pratique : comment stocker, lire et gérer des secrets ? Quelles sont les bonnes pratiques pour structurer les chemins ? Et comment exploiter au mieux le versionnage de KV v2 ?
Restez avec nous - la suite sera concrète !
