Les Secrets Engines sont le cœur de Vault - ils permettent d'envisager la sécurité non seulement comme une question de stockage, mais comme un véritable processus. Qu'il s'agisse d'un mot de passe de base de données, d'un accès SSH ou de la signature d'un JWT : tout peut être géré de manière dynamique, sécurisée et traçable - à condition de connaître les bons Engines et de les utiliser correctement. La clé ne réside pas tant dans la diversité que dans la compréhension et le design. Quiconque souhaite utiliser Vault de manière productive ne peut faire l’impasse sur une compréhension approfondie des Secrets Engines.
Cet article offre un aperçu solide des fonctions, cas d’usage et cycles de vie des Secrets Engines - des Engines génériques comme KV, Transit ou PKI jusqu’aux modules spécialisés pour les plateformes Cloud et de bases de données.
Que sont les Secrets Engines ?
Les Secrets Engines sont des composants spécialisés à l’intérieur de Vault, qui stockent, génèrent ou chiffrent des données sensibles, ou exécutent des actions au nom de l’utilisateur. On peut considérer un Secrets Engine comme un « service enfichable » activé dans Vault via un chemin dédié et assumant différentes fonctions selon son type.
Certains Secrets Engines servent principalement de stockage sécurisé - comparable à un Redis ou un Memcached chiffré. D’autres interagissent avec des systèmes externes et génèrent dynamiquement des identifiants d’accès, par exemple pour AWS IAM, les bases de données Oracle ou les accès SSH. D’autres encore offrent des services cryptographiques tels que Encryption as a Service, la génération de TOTP et de codes QR, ou la délivrance de certificats.
D’un point de vue technique, chaque Secrets Engine fonctionne comme un système de fichiers virtuel, avec lequel les utilisateurs interagissent via des opérations telles que read, write ou delete. Une requête adressée à Vault est automatiquement dirigée vers le chemin responsable, où l’Engine est « monté ». Chaque Engine définit alors son propre ensemble de chemins et de fonctions.
Types de Secrets Engines : aperçu de l’écosystème Vault
Vault propose un large éventail de Secrets Engines, que l’on peut grossièrement répartir en deux catégories :
Secrets Engines spécialisés
Ces Engines sont conçus pour des plateformes et services spécifiques, et nécessitent généralement une expertise approfondie de la plateforme cible :
- Cloud : AWS, Azure, Google Cloud, AliCloud
- Bases de données : Cassandra, Couchbase, ElasticSearch, HANA, IBM DB2, Influx DB, MongoDB, MongoDB Atlas, MSSQL, MariaDB, MySQL, Oracle Database, PostgreSQL, Redis, Redis Elasticache, Redshift, Snowflake
- Services d’identité : Kerberos, LDAP, divers services cloud y compris OCI, RADIUS, SAML, JWT/OIDC, Okta, Github, CloudFoundry, etc.
- Outils d’infrastructure : Consul, Nomad, Terraform Cloud
- Messagerie : RabbitMQ
- Autres : Venafi, SSH, TOTP, Transform, divers KMS externes, etc.
Il est important de noter qu’un Vault Engineer ne peut pas être expert de toutes les plateformes. La configuration correcte de ces Engines requiert généralement une collaboration étroite avec des experts métier de la plateforme concernée.
Secrets Engines génériques
Ces Engines font partie du répertoire standard et devraient être familiers à tout utilisateur de Vault :
- Cubbyhole : Stockage temporaire de données lié à un token. Idéal pour des secrets privés et éphémères, conservés uniquement en mémoire et pouvant (ou devant) être supprimés après un redémarrage du serveur.
- Key/Value (KV) : Probablement l’Engine le plus répandu pour la définition de clés et de valeurs associées, comme un nom d’utilisateur et un mot de passe. KV v2 prend en charge la gestion de versions, tandis que KV v1 est considéré comme obsolète.
- Database : Prend en charge plus de 13 plateformes via des plugins et permet la création et la révocation automatique d’identifiants de base de données.
- Transit : Fournit des services de chiffrement sans stockage. Idéal pour les applications traitant localement des données sensibles mais nécessitant une gestion centralisée des clés.
- PKI : Crée et gère des certificats X.509 - indispensable pour les solutions d’autorité de certification interne.
- Identity : Permet l’association d’identités, la gestion des alias et l’attribution de politiques.
Secrets Engines pertinents pour les certifications
Dans le cadre d’un examen de certification en tant que Vault Associate ou Vault Operations Professional, il est essentiel de bien connaître les Secrets Engines suivants :
- Cubbyhole
- KV
- Identity
- PKI
- Database
- Transit
Nous examinerons ces Engines plus en détail dans des articles séparés.
Cycle de vie des Secrets Engines
Chaque Secrets Engine suit généralement un cycle de vie : il est
- activé,
- configuré,
- utilisé,
- régulièrement ajusté (« tuné »), et
- désactivé dans de nombreux cas d’usage.
Les Secrets Engines générés de manière dynamique (par exemple pour des bases de données créées automatiquement, des comptes cloud ou des locataires) doivent non seulement être activés, mais aussi régulièrement ajustés, et être désactivés au plus tard lors de la suppression de la composante d’infrastructure concernée. Cela ne constitue pas uniquement un nettoyage, mais aussi une preuve importante de la qualité des données et du respect des exigences réglementaires telles que les obligations en matière de protection des données. C’est pourquoi l’auditabilité de chaque action est un élément central de l’architecture de sécurité de Vault.
Activation et isolation des Secrets Engines
Pour pouvoir utiliser une Secrets Engine, il faut d’abord l’activer - soit via la CLI, l’API ou l’UI.
Les Secrets Engines doivent être activement activées par l’utilisateur (à l’exception de Cubbyhole et Identity, qui sont actives par défaut). L’activation se fait à un chemin unique, librement défini, qui sert de mount point. Vault applique ici les principes suivants :
- Chemins sensibles à la casse : kv/ et KV/ sont deux montages différents
- Pas de conflits de noms : un montage foo/ empêche foo/bar/
- Chaque Engine est isolée : accès uniquement à ses propres données
Caractéristiques importantes qu’un ingénieur et un utilisateur final doivent toujours garder à l’esprit - et qui peuvent à tout moment apparaître dans une épreuve de certification :
- Activées par défaut : Les Engines Cubbyhole et Identity sont préactivées et ne peuvent pas être désactivées.
- Activation manuelle : Toutes les autres Engines nécessitent une activation explicite.
- Méthodes d’activation : L’activation peut se faire via la ligne de commande (CLI), l’API ou l’interface utilisateur (UI).
- Interaction par chemins : Toute interaction avec une Secrets Engine passe par son chemin.
- Chemins isolés : Chaque Engine activée est totalement isolée du reste du système - à la fois logiquement et physiquement. Dans le cas d’un fonctionnement multi-tenant, même les Engines ayant des mount points identiques sont isolées les unes des autres.
- Noms de chemins flexibles : Les chemins n’ont pas besoin de correspondre au nom ou au type de la Secrets Engine.
- Sensibles à la casse : Le chemin est sensible à la casse. Une Engine montée sous kv/ n’est pas identique à KV/.
En arrière-plan, chaque Engine activée reçoit un chemin de stockage généré aléatoirement basé sur une UUID dans la couche de stockage de Vault. Ce chemin est comparable à un chroot. Cette « vue barrière » garantit qu’une Engine ne peut accéder qu’à ses propres données. Même en cas de compromission d’une Engine, l’accès aux autres Secrets Engines est exclu - y compris au sein du même namespace (tenant).
Pro Tip : Il est judicieux de définir une convention de nommage cohérente pour vos Secrets Engines, adaptée à votre organisation. Si vous utilisez des namespaces, des conventions strictes peuvent réduire considérablement la complexité globale du système, ainsi que les risques et les efforts liés à l’exploitation.
Activation via la ligne de commande
La commande vault secrets est le point d’entrée principal pour la gestion des Secrets Engines via la CLI. Les sous-commandes importantes sont :
- disable : désactive une Secrets Engine
- enable : active une nouvelle Secrets Engine
- list : liste toutes les Secrets Engines activées
- move : déplace une Secrets Engine d’un chemin à un autre
- tune : configure les paramètres d’une Secrets Engine
Exemples
1. Activer la Secrets Engine KV (Key/Value) sur le chemin par défaut
[rramge@ol9 ~]$ vault secrets enable kv Success! Enabled the kv secrets engine at: kv/ [rramge@ol9 ~]$
Vérification :
[rramge@ol9 ~]$ vault secrets list Path Type Accessor Description ---- ---- -------- ----------- cubbyhole/ cubbyhole cubbyhole_fe623ade per-token private secret storage identity/ identity identity_cd5a6252 identity store kv/ kv kv_62ea76c1 n/a sys/ system system_b247c51c system endpoints used for control, policy and debugging [rramge@ol9 ~]$
Vous voyez ici, en plus de la Secrets Engine KV, les Secrets Engines Cubbyhole et Identity, car elles sont, comme déjà mentionné, toujours présentes. L’Engine « system » n’est pas destinée au stockage de données, mais au fonctionnement interne de Vault - nous y reviendrons dans des articles ultérieurs, selon les besoins.
2. Activer la Secrets Engine KV (Key/Value) sur un chemin personnalisé :
On ajoute ici l’argument --path=<mount-point> :
[rramge@ol9 ~]$ vault secrets enable -path=mykv kv Success! Enabled the kv secrets engine at: mykv/ [rramge@ol9 ~]$
Vérification :
[rramge@ol9 ~]$ vault secrets list Path Type Accessor Description ---- ---- -------- ----------- cubbyhole/ cubbyhole cubbyhole_fe623ade per-token private secret storage identity/ identity identity_cd5a6252 identity store kv/ kv kv_62ea76c1 n/a mykv/ kv kv_5fa9f096 n/a sys/ system system_b247c51c system endpoints used for control, policy and debugging [rramge@ol9 ~]$
3. Activer la Secrets Engine KV (Key/Value) avec une description personnalisée
Il est également possible d’ajouter l’argument --description :
[rramge@ol9 ~]$ vault secrets enable -path=mykv --description="My K/V Secret Store" kv Success! Enabled the kv secrets engine at: mykv/ [rramge@ol9 ~]$
Le résultat serait alors :
[rramge@ol9 ~]$ vault secrets list Path Type Accessor Description ---- ---- -------- ----------- cubbyhole/ cubbyhole cubbyhole_fe623ade per-token private secret storage identity/ identity identity_cd5a6252 identity store kv/ kv kv_62ea76c1 n/a mykv/ kv kv_645ae3a2 My K/V Secret Store sys/ system system_b247c51c system endpoints used for control, policy and debugging [rramge@ol9 ~]$
4. Désactiver une Secrets Engine
Désactivons à présent les deux Secrets Engines sous kv/ et mykv/ :
[rramge@ol9 ~]$ vault secrets disable mykv Success! Disabled the secrets engine (if it existed) at: mykv/ [rramge@ol9 ~]$ vault secrets disable kv Success! Disabled the secrets engine (if it existed) at: kv/ [rramge@ol9 ~]$
Attention : Si vous désactivez une Secrets Engine existante contenant déjà des secrets, vous risquez de perdre vos données ! La désactivation d’une Secrets Engine supprime toutes les données qui y sont associées - une sauvegarde préalable est fortement recommandée, en particulier pour les Engines persistantes comme KV ou PKI.
Activation via l’API avec Terraform
En plus de la CLI, Vault peut être piloté de manière déclarative via l’API en utilisant Terraform. Vous trouverez un module Terraform pour la gestion des Secrets Engines et de leurs propriétés ici : https://github.com/ICT-technology/terraform-vault-mount/
Ce module est un module dynamique permettant de créer et de gérer plusieurs Secrets Engines dans un seul appel de module. Il intercepte de manière proactive les erreurs d’API, applique les bonnes pratiques de gestion des Secrets Engines et prend en charge les pipelines de test automatisés via terraform test.
Exemple d’utilisation
Vous trouverez un exemple fonctionnel dans le sous-dossier examples/. Configurez correctement vos variables d’environnement $VAULT_ADDR et $VAULT_TOKEN, et vous pourrez l’exécuter directement depuis ce sous-dossier - veillez cependant à l’utiliser uniquement dans un environnement de développement privé et non dans un environnement de production.
Le module crée les Secrets Engines suivantes :
- kv-v2
- pki
- kubernetes
- ldap
- transit
- aws
Après un terraform apply réussi, le module produira une liste de mount-accessors correspondant aux Secrets Engines créées. Ces mount-accessors peuvent ensuite être utilisés comme référence dans la configuration d’autres ressources Terraform, mais aussi pour des cas comme l’audit et l’attribution dynamique de policies.
examples/main.tf :
### BEGIN FILE: examples/main.tf ###
module "vault_mounts" {
source = "git::https://github.com/ICT-technology/terraform-vault-mount.git?ref=v2025.1.3"
mounts = {
kvv2 = {
path = "kv-v2"
type = "kv-v2"
description = "Key-Value Version 2 Secrets Engine"
options = { version = "2" }
}
pki = {
path = "pki"
type = "pki"
description = "PKI Secrets Engine"
default_lease_ttl_seconds = 3600
max_lease_ttl_seconds = 86400
}
kubernetes = {
path = "kubernetes"
type = "kubernetes"
description = "Kubernetes Auth Engine"
}
ldap = {
path = "ldap"
type = "ldap"
description = "LDAP Auth Engine"
options = { case_sensitive_names = "true" }
}
transit = {
path = "transit"
type = "transit"
description = "Transit Secrets Engine for Encryption-as-a-Service"
options = {
convergent_encryption = false
}
}
aws = {
path = "aws"
type = "aws"
description = "AWS Secrets Engine"
}
}
}
### END FILE: examples/main.tf ###examples/outputs.tf :
### BEGIN FILE: examples/outputs.tf ###
output "mount\_accessors" {
description = "Accessors for the configured Vault mounts"
value = module.vault\_mounts.mount\_accessor
}
### END FILE: examples/outputs.tf ###Dans la pratique, un terraform apply sur cet exemple se présentera comme suit :
[rramge@ol9 examples]$ terraform apply
[...]
Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. Enter a value: yes module.vault\_mounts.vault\_mount.this\["aws"]: Creating... module.vault\_mounts.vault\_mount.this\["transit"]: Creating... module.vault\_mounts.vault\_mount.this\["kvv2"]: Creating... module.vault\_mounts.vault\_mount.this\["ldap"]: Creating... module.vault\_mounts.vault\_mount.this\["kubernetes"]: Creating... module.vault\_mounts.vault\_mount.this\["pki"]: Creating... module.vault\_mounts.vault\_mount.this\["aws"]: Creation complete after 1s \[id=aws] module.vault\_mounts.vault\_mount.this\["pki"]: Creation complete after 1s \[id=pki] module.vault\_mounts.vault\_mount.this\["transit"]: Creation complete after 1s \[id=transit] module.vault\_mounts.vault\_mount.this\["kvv2"]: Creation complete after 1s \[id=kv-v2] module.vault\_mounts.vault\_mount.this\["kubernetes"]: Creation complete after 1s \[id=kubernetes] module.vault\_mounts.vault\_mount.this\["ldap"]: Creation complete after 1s \[id=ldap] Apply complete! Resources: 6 added, 0 changed, 0 destroyed. Outputs: mount\_accessors = { "aws" = "aws\_e2982916" "kubernetes" = "kubernetes\_6671be50" "kvv2" = "kv\_26a6e11a" "ldap" = "ldap\_8fbb6083" "pki" = "pki\_2d96cba8" "transit" = "transit\_25465e3f" } \[rramge\@ol9 examples]\$
Activation via l’interface web
Il est également possible d’activer les Secrets Engines via une interface web. Vault propose une interface Web UI activable en option, assez minimaliste et davantage conçue comme vitrine pour des présentations marketing que pour une utilisation administrative dans des environnements de production à grande échelle.
Je n’aborderai pas ici cette interface web - je pars du principe qu’en tant que lecteur techniquement compétent et expérimenté, vous saisissez l’importance et la nécessité de processus de configuration reproductibles et de l’automatisation dans un contexte de sécurité, plutôt que de privilégier les clics souris. Apprenez à maîtriser les commandes CLI et comprenez la valeur de l’Infrastructure-as-Code, car cela est indispensable aussi bien en pratique que comme préparation à une certification.
Perspectives
Dans le prochain article approfondi sur HashiCorp Vault, nous jetterons un premier regard sur la Secrets Engine Key/Value avant d’y plonger en détail.
