Vault

De wiki.nexiat.fr
Aller à la navigation Aller à la recherche
Fiche express
Type Gestion de secrets et chiffrement centralisés
Éditeur HashiCorp (BUSL depuis 2023, fork libre : OpenBao)
Moteurs de secrets KV, PKI, Database, Transit, Cloud (AWS/Azure/GCP)...
Authentification Token, AppRole, Kubernetes, LDAP, OIDC...
Voir aussi PKI · Terraform — Concepts fondamentaux · Ansible

Vault est un outil de gestion de secrets édité par HashiCorp. Il centralise l'accès aux informations sensibles (mots de passe, clés d'API, certificats, identifiants de base de données) derrière une politique d'accès fine et un journal d'audit, plutôt que de les laisser dispersés en clair dans des fichiers de configuration, un dépôt Git ou des variables d'environnement. Vault ne se contente pas de stocker des secrets statiques : il peut aussi en générer dynamiquement, à la demande, avec une durée de vie limitée.

Chiffrement au repos et en transit

Toutes les données gérées par Vault sont chiffrées au repos dans son backend de stockage (fichier, Consul, intégré Raft...) et échangées en transit via TLS. Les données ne sont jamais stockées en clair, y compris pour l'opérateur du backend de stockage lui-même : le chiffrement passe par une clé maîtresse protégée par le mécanisme de scellement.

Scellement (seal/unseal)

Au démarrage, un serveur Vault est scellé (sealed) : la clé de chiffrement des données n'est pas en mémoire et aucune opération n'est possible. Le déscellement (unseal) classique repose sur le partage de secret de Shamir : la clé maîtresse est fractionnée en plusieurs parts (ex. 5), dont un quorum (ex. 3) doit être réuni pour reconstituer temporairement la clé en mémoire. En production, ce processus manuel est le plus souvent remplacé par un auto-unseal délégué à un service de gestion de clés externe (KMS cloud, HSM), qui déverrouille Vault automatiquement au redémarrage.

<mermaid> flowchart LR 

   S[Vault scellé
sealed] -->|quorum de parts Shamir
ou auto-unseal via KMS| U[Vault déscellé
unsealed, opérationnel]
   U -->|redémarrage / crash| S

</mermaid>

Moteurs de secrets

Un secrets engine est un plugin monté sous un chemin (path) de l'API Vault, chacun avec sa propre sémantique :

  • KV (Key/Value) — stockage de secrets statiques (v1 sans versionning, v2 avec historique de versions et possibilité de restauration).
  • PKI — Vault agit comme autorité de certification interne : génération de certificats X.509 à courte durée de vie, à la volée, via un simple appel API. Voir la catégorie PKI pour les fondamentaux (chaîne de confiance, formats, révocation) que ce moteur met en œuvre de façon automatisée et programmable.
  • Database — génère des identifiants de connexion à une base de données (PostgreSQL, MySQL...) dynamiquement, avec un TTL, et révoque automatiquement le compte à expiration.
  • Transit — chiffrement/déchiffrement « as a service » : les applications envoient des données à chiffrer à Vault via API sans jamais détenir elles-mêmes la clé de chiffrement (encryption as a service).
  • Cloud (AWS, Azure, GCP) — génère des identifiants cloud temporaires à la demande, avec des droits IAM scoping éphémères.
# Activer et utiliser un moteur KV v2
vault secrets enable -path=secret kv-v2
vault kv put secret/app/db password="s3cr3t"
vault kv get secret/app/db

# Générer un certificat via le moteur PKI
vault write pki/roles/webserver \
  allowed_domains="example.org" allow_subdomains=true max_ttl="72h"
vault write pki/issue/webserver common_name="app.example.org" ttl="24h"

# Générer des identifiants de base de données dynamiques
vault read database/creds/readonly-role

Leases et révocation

Chaque secret dynamique émis par Vault est accompagné d'un bail (lease) : une durée de vie (TTL) au-delà de laquelle le secret est automatiquement révoqué. Un client peut renouveler le bail avant expiration s'il en a encore besoin. Cette approche réduit fortement la fenêtre d'exposition d'un identifiant compromis, comparée à un mot de passe statique valable indéfiniment.

Méthodes d'authentification

Vault ne fait pas confiance par défaut : tout client doit s'authentifier auprès d'une méthode d'auth (auth method) pour obtenir un token, auquel sont ensuite attachées des politiques.

  • Token — méthode de base, souvent utilisée en interactif ou en bootstrap.
  • AppRole — méthode pensée pour les workloads applicatifs et l'automatisation (pipelines CI, machines) : un role_id (identifiant, non secret) combiné à un secret_id (à durée de vie limitée, distribué de façon sécurisée) permet d'obtenir un token sans identité humaine.
  • Kubernetes auth — un pod s'authentifie en présentant son service account token (JWT) ; Vault le valide auprès de l'API Kubernetes et attribue des politiques selon le namespace/service account d'origine — méthode de référence pour qu'ArgoCD/Flux ou des workloads applicatifs récupèrent des secrets sans identifiant statique embarqué.
  • LDAP / OIDC — délégation à un annuaire d'entreprise ou un fournisseur d'identité existant, pour les accès humains.

Politiques d'accès

Une policy Vault, écrite dans un langage déclaratif proche du HCL, définit les chemins accessibles et les opérations autorisées (create, read, update, delete, list) : 

path "secret/data/app/*" {
  capabilities = ["read", "list"]
}

path "database/creds/readonly-role" {
  capabilities = ["read"]
}

Une policy est attachée à un token (directement ou via la méthode d'auth utilisée), selon le principe du moindre privilège : une application n'obtient jamais un accès plus large que le strict nécessaire à sa fonction.

Intégration avec l'IaC déjà en place

  • Terraform — le provider Vault permet de lire des secrets depuis un plan/apply, ou à l'inverse de piloter Vault lui-même (création de policies, de rôles) comme n'importe quelle autre ressource ; voir Terraform — Concepts fondamentaux pour le cycle plan/apply et la question voisine du chiffrement du state (un state Terraform contient lui aussi des secrets en clair, sujet distinct mais complémentaire).
  • Ansible — le plugin de lookup community.hashi_vault permet à un playbook de récupérer un secret Vault au moment de l'exécution plutôt que de le stocker dans Ansible Vault (chiffrement local par mot de passe partagé, moins granulaire) ; voir Ansible.

Note : licence et OpenBao

Comme Terraform, Vault est passé sous licence BUSL en 2023 (source-available, non OSI). Un fork communautaire, OpenBao (Linux Foundation), reprend la base sous licence MPL 2.0. Les concepts de cette page (moteurs de secrets, seal/unseal, policies) s'appliquent à l'identique aux deux projets (à vérifier selon l'évolution respective des deux codebases).

Voir aussi

Récupérée de "https://wiki.nexiat.fr/index.php?title=Vault&oldid=2543"