HashiCorp Vault est un coffre-fort de secrets qui centralise le stockage, l'accès et la rotation de vos données sensibles. Au lieu de disperser vos mots de passe, clés API et certificats dans des fichiers de config ou des variables d'environnement, Vault les protège avec du chiffrement, un contrôle d'accès granulaire et un journal d'audit complet.
Cette page est une page pivot de décision. Elle vous aide à évaluer si Vault correspond à votre contexte, quelle édition choisir, et ce que la licence BSL implique concrètement. Les guides pratiques vous accompagnent ensuite pas à pas.
À qui s'adresse Vault ?
Section intitulée « À qui s'adresse Vault ? »Vault est un outil puissant mais complexe. Avant de l'adopter, posez-vous la question : ai-je vraiment besoin de cette complexité ?
Quand Vault est un bon choix
Section intitulée « Quand Vault est un bon choix »Vault devient pertinent quand vous avez au moins un de ces besoins :
| Besoin | Pourquoi Vault excelle |
|---|---|
| Secrets dynamiques | Credentials base de données, cloud, SSH générés à la demande avec TTL |
| PKI interne | Autorité de certification intégrée, certificats courts (heures/jours) |
| Chiffrement applicatif | Transit : l'application n'a jamais accès aux clés de chiffrement |
| Audit fort | Journal complet de qui accède à quoi, quand, pour quelle raison |
| Multi-équipes | Isolation des secrets par équipe/environnement avec policies ACL |
| Rotation / révocation | Révocation instantanée, rotation automatique des credentials |
| Intégration Kubernetes | Auth native via ServiceAccount, injection de secrets |
| Fédération d'identité | Authentification unifiée OIDC, LDAP, cloud providers |
Quand Vault est probablement surdimensionné
Section intitulée « Quand Vault est probablement surdimensionné »Pour certains cas, Vault apporte plus de complexité que de valeur :
| Situation | Alternative plus simple |
|---|---|
| Quelques secrets d'équipe | Gestionnaire de mots de passe (Bitwarden, 1Password) |
| Secrets CI/CD simples | Variables secrètes GitLab/GitHub, AWS Secrets Manager |
| Équipe < 10 personnes, mono-env | SOPS + Git, Infisical, Doppler |
| Pas de budget ops dédié | Solution managée (HCP Vault, Infisical Cloud) |
| Besoin ponctuel de certificats | Let's Encrypt, Certbot |
Ce que Vault vous oblige à opérer
Section intitulée « Ce que Vault vous oblige à opérer »Vault n'est pas un simple coffre-fort : c'est un composant d'infrastructure avec ses propres exigences opérationnelles.
Responsabilités en production
Section intitulée « Responsabilités en production »Ce tableau est le vrai coût de Vault, celui qui n'apparaît pas dans un tutoriel en mode dev. Chaque ligne est une tâche récurrente à outiller et à documenter, pas une case à cocher une fois. Regardez en priorité les trois premières, initialisation, unsealing et stockage : elles conditionnent la capacité à redémarrer le service après une panne. Un cluster Vault mal préparé sur ces points devient un point de défaillance unique pour toutes les applications qui en dépendent.
| Composant | Ce que vous devez gérer |
|---|---|
| Initialisation | Générer et sécuriser les clés de déverrouillage (unseal keys) |
| Unsealing | Déverrouiller Vault après chaque redémarrage (manuel ou auto-unseal) |
| Stockage | Configurer et maintenir le backend (Raft intégré recommandé) |
| Haute disponibilité | Cluster 3+ nœuds pour la tolérance aux pannes |
| Sauvegardes | Snapshots réguliers du storage Raft |
| Rotation des clés | Rotation périodique de la clé de chiffrement maître |
| Audit | Configurer et monitorer les audit devices (fichier, syslog, socket) |
| Monitoring | Métriques Prometheus, alertes sur les échecs d'auth, expirations |
| Policies | Écrire et maintenir les ACL pour chaque équipe/application |
| TLS | Certificats pour l'API Vault (obligatoire en production) |
Auto-unseal : réduire la complexité
Section intitulée « Auto-unseal : réduire la complexité »Par défaut, Vault nécessite une intervention manuelle après chaque redémarrage (fournir les clés Shamir). En production, l'auto-unseal délègue cette opération à un service de confiance :
| Méthode | Fournisseur | Prérequis |
|---|---|---|
| Cloud KMS | AWS KMS, Azure Key Vault, GCP Cloud KMS | Compte cloud configuré |
| Transit | Un autre cluster Vault | Cluster Vault dédié à l'unseal |
| HSM | PKCS#11 | Hardware Security Module (Enterprise) |
Vault Community vs Enterprise
Section intitulée « Vault Community vs Enterprise »HashiCorp propose deux éditions de Vault. Vault CE couvre 90% des besoins courants : KV, Transit, PKI, Database, SSH, toutes les auth methods, Raft storage, et auto-unseal.
| Ce que vous obtenez | Vault CE | Vault Enterprise |
|---|---|---|
| Secrets engines (KV, Transit, PKI, Database, SSH) | ✅ | ✅ |
| Auth methods (AppRole, K8s, OIDC, LDAP, cloud) | ✅ | ✅ |
| Auto-unseal (Cloud KMS, Transit) | ✅ | ✅ |
| Namespaces (multi-tenancy) | ❌ | ✅ |
| Replication (DR, Performance) | ❌ | ✅ |
| MFA intégrée | ❌ | ✅ |
En résumé : CE suffit pour la majorité des organisations. Enterprise se justifie pour le multi-tenant, la réplication multi-région, ou la compliance stricte. HCP Vault offre une version managée sans charge opérationnelle.
Licence BSL : ce que ça implique
Section intitulée « Licence BSL : ce que ça implique »Depuis août 2023, Vault est sous Business Source License (BSL) 1.1 au lieu de MPL 2.0. C'est une licence source-available, pas open source au sens OSI.
| Usage | Autorisé ? |
|---|---|
| Utiliser Vault en interne | ✅ Oui |
| Déployer pour vos propres applications | ✅ Oui |
| Services de conseil autour de Vault | ✅ Oui |
| Créer une offre managée concurrente à HCP Vault | ❌ Non |
En pratique : si vous utilisez Vault pour vos besoins internes ou en tant que consultant, vous n'êtes pas impacté. La restriction cible les offres "Vault-as-a-Service" concurrentes.
Depuis février 2025, HashiCorp appartient à IBM. À ce jour, ni la licence BSL ni la disponibilité de Vault CE n'ont changé. Mais si la pérennité open source est un critère de décision pour vous, ce rachat renforce l'intérêt de connaître l'alternative OpenBao, détaillée plus bas.
Architecture de Vault
Section intitulée « Architecture de Vault »Vault repose sur quatre composants principaux qui interagissent pour sécuriser vos secrets.
Vue d'ensemble
Section intitulée « Vue d'ensemble »Le schéma ci-dessous suit le flux d'accès à un secret, du client jusqu'à la valeur déchiffrée. Deux points méritent l'attention en le lisant. Toute requête traverse d'abord une auth method, qui délivre un token, puis une policy, qui décide de ce que ce token peut faire ; le secret n'est atteint qu'après ces deux barrières. Et rien ne fonctionne tant que le barrier, la couche de chiffrement, n'est pas descellé : c'est l'état sealed contre unsealed détaillé plus bas.
Le système d'identité (Identity)
Section intitulée « Le système d'identité (Identity) »Un point souvent sous-estimé : Vault maintient un système d'identité qui consolide les différentes méthodes d'authentification.
- Entity : représente une personne ou une application unique
- Alias : lie une entity à une auth method (ex: alice via userpass + alice via OIDC = même entity)
- Group : regroupe des entities pour leur appliquer des policies communes
Cela permet d'avoir une vision unifiée des accès même si vous utilisez plusieurs auth methods (userpass pour le dev, OIDC pour la prod, Kubernetes pour les pods).
Sealed vs Unsealed
Section intitulée « Sealed vs Unsealed »Vault démarre scellé (sealed). Dans cet état, il refuse toute opération : les données sont chiffrées avec une clé maître elle-même chiffrée.
Pour devenir opérationnel, Vault doit être déverrouillé (unsealed) :
| Mode | Fonctionnement |
|---|---|
| Shamir (défaut) | La clé maître est divisée en N parts, M sont nécessaires |
| Auto-unseal | Un service externe (KMS, Transit) détient la clé |
En production, configurez l'auto-unseal pour éviter les interventions manuelles après chaque redémarrage.
Secrets Engines : le cœur de Vault
Section intitulée « Secrets Engines : le cœur de Vault »Un secrets engine est un module que vous activez sur un chemin de montage donné et qui définit comment Vault traite les secrets à cet endroit. Chaque engine a un rôle précis : stocker des valeurs, générer des credentials à la demande, chiffrer des données, émettre des certificats. Vous n'activez que les engines dont vous avez l'usage, et chacun est monté sur un chemin distinct que les policies contrôlent séparément.
Deux familles de secrets
Section intitulée « Deux familles de secrets »Vault distingue deux approches fondamentalement différentes :
Les secrets statiques sont des valeurs que vous déposez dans Vault (mot de passe, clé API). Vault les conserve chiffrés jusqu'à ce que vous les modifiiez ou les supprimiez. C'est simple, mais le secret reste le même tant que vous ne le changez pas manuellement, avec tous les problèmes que cela pose.
Les secrets dynamiques sont générés à la demande par Vault. Au lieu de stocker un mot de passe PostgreSQL, vous configurez Vault pour qu'il crée un nouvel utilisateur PostgreSQL à chaque demande, avec une durée de vie limitée (1 heure, 1 jour...). Quand le bail expire, Vault supprime automatiquement l'utilisateur. Personne ne partage jamais le même credential.
Les engines les plus utiles
Section intitulée « Les engines les plus utiles »Vault propose une trentaine d'engines, mais une poignée couvre la grande
majorité des usages. Repérez d'abord la colonne Famille : elle vous dit si
l'engine stocke une valeur figée (Statique), en fabrique une jetable
(Dynamique) ou transforme une donnée sans jamais la stocker
(Chiffrement). Le passage du statique au dynamique est le vrai gain de
Vault : Database, PKI, SSH et les engines cloud suppriment le
credential partagé et permanent qui traîne aujourd'hui dans vos configurations.
| Engine | Famille | Ce qu'il fait concrètement |
|---|---|---|
| KV v2 | Statique | Votre coffre-fort classique : stockez n'importe quel secret avec versioning (10 dernières versions conservées) |
| Transit | Chiffrement | Vault chiffre/déchiffre vos données sans jamais vous donner la clé. Votre app envoie du texte clair, reçoit du chiffré. |
| Database | Dynamique | Crée un user PostgreSQL/MySQL/MongoDB à la demande, le supprime automatiquement après expiration |
| PKI | Dynamique | Fabrique des certificats TLS signés par votre CA interne, avec la durée que vous voulez (1 heure, 30 jours...) |
| SSH | Dynamique | Signe les clés SSH ou génère des mots de passe OTP pour accéder à vos serveurs |
| AWS/Azure/GCP | Dynamique | Génère des credentials cloud temporaires (IAM user, service account...) |
| Cubbyhole | Statique | Coffre-fort personnel lié à votre token, personne d'autre ne peut y accéder, même les admins |
Quel engine pour quel besoin ?
Section intitulée « Quel engine pour quel besoin ? »Ce tableau prend le problème par l'autre bout : partez de votre besoin réel, il
vous renvoie vers l'engine adapté. Une règle de lecture aide à décider vite. Si
le secret vous est imposé de l'extérieur (clé API d'un fournisseur tiers),
vous n'avez pas le choix, c'est du statique en KV v2. Dès que Vault peut
créer et détruire le credential lui-même, préférez toujours l'engine
dynamique correspondant : c'est lui qui élimine le mot de passe partagé.
| Votre besoin | Engine recommandé | Pourquoi |
|---|---|---|
| Stocker des clés API tierces | KV v2 | Secrets statiques imposés par le fournisseur |
| Accès base de données pour vos apps | Database | Plus de mot de passe partagé, rotation automatique |
| Chiffrer des données sensibles (RGPD) | Transit | Vos développeurs n'ont jamais accès aux clés |
| Certificats TLS internes (mTLS) | PKI | Certificats courts, révocation facile |
| Accès SSH à vos serveurs | SSH | Plus de clés SSH qui traînent, accès audité |
| Credentials AWS temporaires | AWS | Plus de access keys permanentes dans les configs |
Méthodes d'authentification : prouver son identité
Section intitulée « Méthodes d'authentification : prouver son identité »Avant d'accéder à un secret, vous devez prouver qui vous êtes. Vault propose plusieurs méthodes selon que vous êtes un humain ou une machine.
Le problème de l'authentification machine
Section intitulée « Le problème de l'authentification machine »Pour un humain, c'est simple : vous tapez un mot de passe ou vous utilisez votre SSO d'entreprise. Mais comment une application prouve-t-elle son identité ? Elle ne peut pas taper de mot de passe.
C'est là qu'interviennent les méthodes d'auth spécialisées :
- AppRole : l'application reçoit un "role_id" (son identité) et un "secret_id" (son mot de passe jetable). Le secret_id peut être à usage unique.
- Kubernetes : le pod utilise son ServiceAccount token. Vault vérifie auprès de l'API Kubernetes que le pod est bien celui qu'il prétend être.
- AWS/Azure/GCP : l'instance cloud utilise son identité machine (instance metadata). Vault vérifie auprès du cloud provider.
Quelle méthode pour qui ?
Section intitulée « Quelle méthode pour qui ? »Le critère de choix est la nature de celui qui s'authentifie. Un humain
passe par un login classique (userpass) en local ou par le SSO de
l'entreprise (OIDC, LDAP) en production. Une machine ne tape pas de mot
de passe : elle prouve son identité via son environnement, le ServiceAccount
d'un pod, l'identité d'une instance cloud, ou un couple role_id/secret_id
avec AppRole. Repérez votre ligne, la colonne de droite décrit le mécanisme
de vérification.
| Qui s'authentifie | Méthode recommandée | Comment ça marche |
|---|---|---|
| Développeur en local | Userpass | Login/mot de passe classique, simple pour les tests |
| Employé en entreprise | OIDC ou LDAP | SSO via Keycloak, Okta, Azure AD, ou Active Directory |
| Pipeline CI/CD | AppRole | role_id en variable, secret_id généré à chaque run |
| Pod Kubernetes | Kubernetes auth | ServiceAccount token vérifié par Vault |
| Instance EC2/VM cloud | AWS/Azure/GCP auth | L'identité machine du cloud provider |
| Serveur on-premise | AppRole ou TLS certs | Selon votre infrastructure |
Pourquoi pas juste des tokens ?
Section intitulée « Pourquoi pas juste des tokens ? »Les tokens Vault fonctionnent, mais ils ont un problème : vous devez les créer et les distribuer manuellement. Si vous avez 50 microservices, ça devient ingérable. Les auth methods permettent aux applications de s'authentifier elles-mêmes et de recevoir un token automatiquement.
Policies : le principe du moindre privilège en action
Section intitulée « Policies : le principe du moindre privilège en action »Une fois authentifié, que pouvez-vous faire ? C'est le rôle des policies. Elles définissent précisément quels secrets vous pouvez lire, modifier ou supprimer.
Anatomie d'une policy
Section intitulée « Anatomie d'une policy »Une policy Vault est un fichier HCL qui associe des chemins à des capabilities, autrement dit des actions autorisées. Le mécanisme central à comprendre est celui du refus par défaut : Vault n'accorde que ce qui est explicitement écrit, tout le reste est interdit. Dans l'exemple ci-dessous, l'équipe a les pleins droits sur les secrets de développement, la lecture seule sur la pré-production, et aucun accès à la production, puisque ce chemin n'apparaît nulle part et n'a donc pas besoin d'être mentionné.
# Policy pour l'équipe développement# Accès complet aux secrets de devpath "secret/data/dev/*" { capabilities = ["create", "read", "update", "delete", "list"]}
# Lecture seule sur staging (pas de modification en pré-prod)path "secret/data/staging/*" { capabilities = ["read", "list"]}
# Aucun accès à la production (implicite : tout ce qui n'est pas# explicitement autorisé est refusé)Décryptage ligne par ligne :
path "secret/data/dev/*": cette règle s'applique à tout ce qui commence par ce chemin. Le*est un wildcard.capabilities: la liste des actions autorisées sur ce chemin.- Par défaut, tout est refusé. Une policy n'accorde que ce qui est explicitement listé.
Les capabilities expliquées
Section intitulée « Les capabilities expliquées »| Capability | Ce que ça permet | Exemple concret |
|---|---|---|
read | Lire la valeur d'un secret | Récupérer le mot de passe de la base de données |
list | Voir la liste des secrets (pas leur contenu) | Savoir qu'il existe un secret "db-password" sans le lire |
create | Créer un nouveau secret | Ajouter une nouvelle clé API |
update | Modifier un secret existant | Changer le mot de passe |
delete | Supprimer un secret | Retirer une clé API révoquée |
sudo | Actions d'administration | Modifier les policies, gérer les auth methods |
deny | Refuser explicitement (prioritaire sur tout) | Bloquer l'accès même si une autre policy l'autorise |
Bonnes pratiques pour les policies
Section intitulée « Bonnes pratiques pour les policies »Les quatre règles suivantes évitent les dérives les plus fréquentes sur des
policies qui vivent longtemps. La plus structurante est la première : une
policy par rôle métier plutôt qu'une policy par personne, sinon leur nombre
explose et personne ne sait plus qui a accès à quoi. La troisième, pas de
wildcard sur la production, ferme la porte à l'accident où un * trop large
expose un secret critique. Vérifiez toujours la syntaxe avec vault policy fmt
avant de charger une policy, une erreur de format s'y glisse facilement.
- Une policy par rôle métier :
policy-dev-team,policy-ci-runner,policy-prod-readonly - Moindre privilège : accordez uniquement ce qui est nécessaire
- Pas de wildcards sur la prod :
secret/data/prod/db-*plutôt quesecret/data/prod/* - Testez avant de déployer :
vault policy fmtvérifie la syntaxe
Vault vs OpenBao : le fork open source
Section intitulée « Vault vs OpenBao : le fork open source »OpenBao est un fork de Vault créé en 2023 après le changement de licence. Maintenu par la Linux Foundation sous licence MPL 2.0, il offre une alternative 100% open source.
| Critère | Vault CE | OpenBao |
|---|---|---|
| Licence | BSL 1.1 | MPL 2.0 (OSI) |
| Namespaces | ❌ Enterprise only | ✅ Inclus |
| Maturité | 10+ ans | 2+ ans |
| Écosystème | Large | En croissance |
En résumé :
- Vault si vous avez besoin de l'écosystème mature ou envisagez Enterprise
- OpenBao si la licence OSI est requise ou si vous voulez les namespaces sans payer
Cas d'usage recommandés
Section intitulée « Cas d'usage recommandés »Cette page défend une idée simple : Vault n'est pas toujours la bonne réponse.
Le tableau récapitule le raisonnement de décision profil par profil. La ligne
qui surprend le plus est la première : pour une petite équipe, un outil plus
léger (Infisical, Doppler, SOPS) rend souvent plus de service que Vault,
car le coût opérationnel de ce dernier dépasse le bénéfice. Vault et OpenBao
deviennent le bon choix dès qu'apparaissent le multi-équipes, la PKI interne
ou le chiffrement applicatif.
| Profil | Solution recommandée | Pourquoi |
|---|---|---|
| Petite équipe (< 10 dev) | Infisical, Doppler, SOPS | Moins de complexité opérationnelle |
| Startup / équipe moyenne | Vault CE ou OpenBao | Bon rapport puissance/complexité |
| Plateforme interne multi-équipes | Vault Enterprise ou OpenBao | Namespaces, isolation |
| Kubernetes-first | External Secrets + (Vault ou OpenBao) | Intégration native |
| PKI interne / mTLS | Vault CE ou OpenBao | Engine PKI complet |
| Chiffrement applicatif | Vault Transit | Les clés ne quittent jamais Vault |
| Compliance stricte | Vault Enterprise | MFA, Sentinel, Control Groups |
| Open source pur requis | OpenBao | Licence MPL 2.0 |
Les guides de cette section
Section intitulée « Les guides de cette section »Comprendre et décider
Section intitulée « Comprendre et décider »Guides pratiques
Section intitulée « Guides pratiques »À retenir
Section intitulée « À retenir »- Vault est puissant mais exigeant : évaluez si vous avez les ressources pour l'opérer
- Vault CE couvre 90% des besoins : KV, Transit, PKI, Database, SSH, auth methods
- Enterprise pour namespaces, réplication, MFA : si vous êtes une plateforme multi-tenant
- Licence BSL : usage interne OK, offre concurrente interdite
- OpenBao : alternative open source avec namespaces inclus, écosystème en croissance
- Auto-unseal : configurez-le en production pour éviter les interventions manuelles
- Identity system : permet de consolider les identités multi-auth methods
FAQ : questions fréquentes
Section intitulée « FAQ : questions fréquentes »Ces réponses courtes traitent les questions de décision qui reviennent le plus avant d'adopter Vault : le choix entre édition CE et Enterprise, la portée de la licence BSL, le positionnement de l'alternative OpenBao et le fonctionnement des secrets dynamiques.
sudo apt install vault
vault version
vault server -dev, tout en mémoire, non sécurisé). En production, configurez un backend Raft et l'auto-unseal, puis initialisez avec vault operator init. Le guide détaille chaque étape : Installer Vault.