HashiCorp Vault : gérez vos secrets en toute sécurité

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 ?

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

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é

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

Vault n’est pas un simple coffre-fort : c’est un composant d’infrastructure avec ses propres exigences opérationnelles.

Responsabilités en production

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é

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

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

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.

Architecture de Vault

Vault repose sur quatre composants principaux qui interagissent pour sécuriser vos secrets.

Vue d’ensemble

Architecture Vault - Flux d'accès aux secrets

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

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

Imaginez Vault comme un immeuble de bureaux sécurisé. Chaque “secrets engine” est un étage spécialisé : un étage pour les coffres-forts classiques, un autre pour la fabrication de clés temporaires, un troisième pour l’émission de badges d’accès. Vous activez uniquement les étages dont vous avez besoin.

Deux familles de secrets

Vault distingue deux approches fondamentalement différentes :

Les secrets statiques fonctionnent comme un coffre-fort traditionnel. Vous y déposez un secret (mot de passe, clé API), et Vault le conserve jusqu’à ce que vous le modifiiez ou le 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 fonctionnent comme une usine à credentials. 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 temps expire, Vault supprime automatiquement l’utilisateur. Personne ne partage jamais le même credential.

Les engines les plus utiles

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 ?

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é

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

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 ?

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 ?

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

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.

L’analogie des badges d’accès

Pensez aux badges dans un immeuble de bureaux. Votre badge vous donne accès à certains étages et certaines salles, pas à tout le bâtiment. Les policies Vault fonctionnent pareil : elles définissent les “chemins” (paths) auxquels vous avez accès et ce que vous pouvez y faire.

Anatomie d’une policy

# Policy pour l'équipe développement
# Accès complet aux secrets de dev
path "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

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

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 que secret/data/prod/*
Testez avant de déployer : vault policy fmt vérifie la syntaxe

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

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	Keys never leave Vault
Compliance stricte	Vault Enterprise	MFA, Sentinel, Control Groups
Open source pur requis	OpenBao	Licence MPL 2.0

Les guides de cette section

Comprendre et décider

Vault vs OpenBao Comparer Vault et le fork open source pour faire le bon choix

Éditions CE vs Enterprise Fonctionnalités par édition et grille de décision

Licence BSL expliquée Ce que la licence autorise selon votre profil

Auto-unseal et Recovery Keys Comprendre les mécanismes de scellement

Guides pratiques

Installation et configuration Installer Vault, mode dev vs production, initialisation et auto-unseal

Secrets KV : stockage clé-valeur Stocker, versionner et gérer vos secrets statiques

Transit : chiffrement as a service Chiffrer vos données sans gérer les clés

Authentification : userpass et AppRole Configurer l'accès pour utilisateurs et applications

Policies : contrôle d'accès Écrire des policies HCL pour le moindre privilège

PKI : autorité de certification Émettre des certificats TLS avec Vault

Opérer en production Cluster HA, monitoring, sauvegardes et maintenance

À retenir

Vault est puissant mais exigeant : évaluez si vous avez les ressources pour l’opérer
Vault CE couvre 80% 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

Prochaines étapes

Installer Vault Commencez par l'installation et le premier démarrage

Hub Gestion des secrets Vue d'ensemble des pratiques et outils