En août 2023, HashiCorp a changé la licence de Vault de MPL 2.0 vers BSL 1.1. En réponse, la communauté a créé OpenBao, un fork maintenu par la Linux Foundation sous licence MPL 2.0 (100% open source au sens OSI).
Cette page vous aide à choisir entre Vault et OpenBao en fonction de vos contraintes techniques, juridiques et organisationnelles.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- L'histoire du fork et les raisons de la séparation
- Les différences de gouvernance et de licence
- Les fonctionnalités exclusives à chaque solution
- Les critères de décision selon votre contexte
- Les implications d'une migration
Pourquoi deux projets ?
Section intitulée « Pourquoi deux projets ? »L'histoire du fork
Section intitulée « L'histoire du fork »Avant août 2023 : Vault était sous licence MPL 2.0, une licence open source reconnue par l'OSI. Entreprises et communauté pouvaient l'utiliser, le modifier et le redistribuer librement.
Août 2023 : HashiCorp annonce le passage à BSL 1.1 (Business Source License) pour Vault, Terraform, et d'autres produits. Cette licence restreint certains usages commerciaux, notamment la création d'offres concurrentes.
Décembre 2023 : La Linux Foundation annonce OpenBao, un fork de Vault 1.14 (dernière version MPL 2.0) maintenu par la communauté open source.
2024-2026 : OpenBao évolue indépendamment, ajoute des fonctionnalités (namespaces, améliorations auto-unseal), et construit son propre écosystème.
Ce que ça change pour vous
Section intitulée « Ce que ça change pour vous »Le changement de licence n'a pas les mêmes conséquences selon la façon dont vous distribuez le logiciel. Cherchez votre profil dans la première colonne : dans trois cas sur quatre, la BSL ne vous concerne pas du tout. Elle ne devient contraignante que si vous revendez un service construit autour de Vault, ou si votre organisation s'interdit par principe les licences non validées par l'OSI.
| Si vous êtes... | Impact |
|---|---|
| Utilisateur interne | Aucun impact direct, les deux solutions fonctionnent |
| Consultant | Aucun impact, vous pouvez conseiller et déployer les deux |
| Éditeur SaaS | À évaluer selon votre modèle (voir licence BSL) |
| Attaché à l'open source OSI | OpenBao est la seule option |
Tableau comparatif complet
Section intitulée « Tableau comparatif complet »Ce tableau se lit en cherchant les lignes qui divergent, pas en comptant les croix. Sur les briques que vous utiliserez tous les jours (secrets engines, méthodes d'authentification, stockage Raft intégré), les deux produits sont équivalents : c'est la conséquence directe du fork. Les trois lignes qui font vraiment basculer un choix sont la licence, les namespaces et la profondeur de l'écosystème de plugins.
| Critère | Vault CE | OpenBao |
|---|---|---|
| Licence | BSL 1.1 (source-available) | MPL 2.0 (open source OSI) |
| Gouvernance | HashiCorp (IBM depuis février 2025) | Linux Foundation / OpenSSF |
| Base de code | Développement continu | Fork Vault 1.14 + évolutions propres |
| Compatibilité API | Référence | Compatible Vault 1.14 |
| Maturité | 10+ ans, très stable | 2+ ans, en croissance rapide |
| Secrets engines | Complet (KV, Transit, PKI, Database, SSH, cloud) | Identique + évolutions |
| Auth methods | Complet (userpass, AppRole, K8s, OIDC, LDAP, cloud) | Identique |
| Namespaces | ❌ Enterprise only | ✅ Inclus depuis v2.3 |
| Auto-unseal | KMS, Transit, HSM | KMS, Transit, HSM + améliorations |
| Integrated Storage (Raft) | ✅ | ✅ |
| Replication | ❌ Enterprise only | ❌ En développement |
| MFA intégrée | ❌ Enterprise only | ❌ Non prévu |
| Sentinel | ❌ Enterprise only | ❌ Non prévu |
| Plugins | Écosystème large | Compatibilité maintenue, écosystème plus restreint |
| Intégrations cloud | Très complètes | En rattrapage, focus communautaire |
| Support commercial | HashiCorp / IBM | Communauté + vendors (Adfinis, etc.) |
| Documentation | Très complète | En construction, bonne qualité |
Approfondissement des différences clés
Section intitulée « Approfondissement des différences clés »Licence et gouvernance
Section intitulée « Licence et gouvernance »Licence et gouvernance sont deux questions distinctes qu'on confond souvent. La licence dit ce que vous avez le droit de faire du code ; la gouvernance dit qui décide de ce qui entre dans le produit. Vault est permissif à l'usage mais piloté par un seul éditeur, désormais filiale d'IBM. OpenBao est sans restriction d'usage et piloté par une fondation, avec le corollaire habituel : les décisions sont publiques mais plus lentes.
Vault (BSL 1.1) :
- Code source visible et modifiable
- Usage interne autorisé sans restriction
- Restriction : pas d'offre commerciale concurrente
- Gouvernance : HashiCorp décide seul des évolutions
OpenBao (MPL 2.0) :
- Licence open source OSI complète
- Aucune restriction d'usage
- Gouvernance : Linux Foundation, contributions communautaires
- Roadmap publique, décisions collectives
Namespaces : le point de bascule
Section intitulée « Namespaces : le point de bascule »Les namespaces permettent d'isoler complètement des environnements au sein d'un même cluster Vault/OpenBao. Chaque namespace a ses propres secrets, policies, auth methods.
| Solution | Namespaces |
|---|---|
| Vault CE | ❌ Non disponible |
| Vault Enterprise | ✅ Inclus |
| OpenBao | ✅ Inclus depuis v2.3 |
Pourquoi c'est important :
Si vous gérez plusieurs équipes ou clients sur la même infrastructure, les namespaces simplifient considérablement la gestion :
- Isolation complète entre tenants
- Délégation d'administration par namespace
- Pas besoin de déployer plusieurs clusters
Maturité et stabilité
Section intitulée « Maturité et stabilité »La maturité d'OpenBao ne se mesure pas à son âge apparent. Le projet part du code de Vault 1.14, éprouvé pendant des années en production, et ce qui est réellement jeune, ce sont les fonctionnalités ajoutées depuis le fork et le processus de release de la nouvelle équipe. Autrement dit, le risque ne porte pas sur le moteur de secrets, mais sur les briques neuves et sur le nombre d'incidents publics à partir desquels le projet a pu apprendre.
Vault :
- 10+ ans de développement
- Utilisé par des milliers d'entreprises
- Bugs critiques rares, processus de sécurité éprouvé
- Documentation exhaustive
OpenBao :
- 2+ ans depuis le fork
- Communauté active et croissante
- Base de code héritée de Vault, donc solide
- Moins de retours d'expérience en production massive
Écosystème et intégrations
Section intitulée « Écosystème et intégrations »C'est le critère qui coûte le plus cher quand on le découvre trop tard. Un gestionnaire de secrets n'est jamais seul : il est consommé par Terraform, par un opérateur Kubernetes, par un provider Ansible, par vos SDK applicatifs. Chacun de ces éléments s'authentifie contre une API et parle à un secrets engine ; l'inventaire ci-dessous vous indique où chercher les points de friction avant de vous engager.
Vault :
- Plugins officiels pour tous les clouds (AWS, Azure, GCP, Alibaba...)
- Intégrations natives Terraform, Kubernetes, Nomad
- Providers Ansible, Puppet, Chef
- SDKs officiels (Go, Python, Ruby, Java, .NET)
OpenBao :
- Compatibilité API Vault 1.14
- La plupart des outils fonctionnent (avec adaptation parfois)
- Contributions communautaires pour les intégrations
- Focus sur les cas d'usage les plus courants
En pratique : Si vous utilisez un plugin ou une intégration exotique, vérifiez sa compatibilité OpenBao avant de migrer.
Support et communauté
Section intitulée « Support et communauté »Sur un composant qui détient tous vos secrets, la vraie question n'est pas « qui répond aux questions » mais « qui je peux appeler à trois heures du matin quand le cluster refuse de se desceller ». Vault propose un contrat de support avec engagement, OpenBao repose sur la communauté et sur des prestataires tiers. Si vous n'avez ni contrat ni compétence interne, l'écart de documentation entre les deux projets devient votre filet de sécurité.
Vault :
- Support commercial HashiCorp / IBM (payant)
- Community forums
- Documentation officielle complète
- Formations et certifications
OpenBao :
- Communauté active (Slack, GitHub)
- Support commercial via vendors tiers (Adfinis, etc.)
- Documentation en amélioration continue
- Pas de certification officielle
Critères de décision
Section intitulée « Critères de décision »Les trois tableaux qui suivent ne sont pas des listes d'arguments à peser les uns contre les autres : un seul critère suffit à trancher. Si l'une des lignes décrit une contrainte à laquelle vous ne pouvez pas échapper (politique de licence, besoin de multi-tenancy, obligation de support contractuel), la décision est déjà prise et le reste n'est que confort.
Choisissez Vault CE si...
Section intitulée « Choisissez Vault CE si... »Ces cinq critères ont un point commun : ils relèvent tous de l'environnement autour du produit, pas de ses capacités techniques. Vault CE s'impose quand le coût de sortie de l'écosystème HashiCorp dépasse le bénéfice du changement de licence.
| Critère | Pourquoi Vault |
|---|---|
| Écosystème mature requis | Plugins, intégrations, documentation exhaustive |
| Entreprise établie | Processus d'achat HashiCorp déjà en place |
| Évolution vers Enterprise | Chemin de migration naturel |
| Intégrations cloud avancées | Plugins officiels maintenus |
| Formations certifiantes | Programme de certification HashiCorp |
Choisissez OpenBao si...
Section intitulée « Choisissez OpenBao si... »La ligne la plus décisive de ce tableau est celle des namespaces : c'est le seul cas où OpenBao offre gratuitement une fonctionnalité que Vault réserve à son édition Enterprise. Les autres critères sont des questions de principe ou de budget, celui-ci est une différence fonctionnelle nette.
| Critère | Pourquoi OpenBao |
|---|---|
| Licence OSI requise | Politique d'entreprise, choix éthique |
| Namespaces sans Enterprise | Multi-tenancy incluse gratuitement |
| Indépendance vendor | Gouvernance Linux Foundation |
| Contribution souhaitée | Projet communautaire ouvert |
| Budget restreint | Pas de coût de licence, support communautaire |
Choisissez Vault Enterprise si...
Section intitulée « Choisissez Vault Enterprise si... »Ces critères ne sont ni du confort ni de l'optimisation : ce sont des besoins qu'aucune des deux éditions gratuites ne couvre. La réplication est le plus fréquent, parce qu'elle conditionne la reprise d'activité sur un second site ; les autres relèvent d'obligations de conformité ou d'un module matériel de sécurité déjà en place.
| Critère | Pourquoi Enterprise |
|---|---|
| Multi-région | Replication DR et Performance |
| Compliance stricte | MFA, Control Groups, Sentinel |
| Support commercial | SLA, hotline, consulting |
| HSM seal wrap | Protection hardware des données |
| Autopilot avancé | Auto-upgrade, redundancy zones |
Grille de décision rapide
Section intitulée « Grille de décision rapide »Si vous ne deviez lire qu'une section de cette page, ce serait celle-ci. Cherchez la ligne qui ressemble le plus à votre situation actuelle, pas à celle que vous projetez dans trois ans : migrer un gestionnaire de secrets est une opération courte et documentée, sur-dimensionner votre choix aujourd'hui coûte plus cher que de changer plus tard.
| Votre situation | Recommandation |
|---|---|
| Petite équipe, usage interne simple | Vault CE ou OpenBao (équivalent) |
| Multi-équipes, besoin namespaces, budget limité | OpenBao |
| Politique open source OSI stricte | OpenBao |
| Écosystème HashiCorp existant (Terraform, Nomad) | Vault CE |
| Évolution Enterprise envisagée | Vault CE |
| Multi-région, DR, compliance | Vault Enterprise |
| Intégrations cloud exotiques | Vault CE (vérifier compatibilité OpenBao) |
Migration entre les solutions
Section intitulée « Migration entre les solutions »De Vault CE vers OpenBao
Section intitulée « De Vault CE vers OpenBao »La migration est relativement simple car OpenBao est compatible avec le format de stockage Vault 1.14.
Procédure générale :
- Snapshot du stockage Raft actuel
- Arrêt du cluster Vault
- Installation d'OpenBao
- Restore du snapshot
- Vérification des secrets, policies, auth methods
- Mise à jour des clients (généralement transparente)
De Vault Enterprise vers OpenBao
Section intitulée « De Vault Enterprise vers OpenBao »La migration est plus complexe :
- Le format de stockage Raft diffère (features Enterprise)
- Les namespaces Enterprise ont une structure différente
- Certaines fonctionnalités n'ont pas d'équivalent
Des vendors comme Adfinis proposent des outils et services de migration.
D'OpenBao vers Vault
Section intitulée « D'OpenBao vers Vault »Théoriquement possible, mais rarement nécessaire. La procédure inverse (snapshot/restore) fonctionne, mais vérifiez les versions API.
Coexistence et stratégie hybride
Section intitulée « Coexistence et stratégie hybride »Certaines organisations choisissent de faire cohabiter les deux :
- Vault Enterprise pour les environnements critiques (prod, compliance)
- OpenBao pour les environnements de développement et test
- Migration progressive pour évaluer OpenBao avant un basculement complet
Cette approche permet de :
- Réduire les coûts de licence
- Tester OpenBao sans risque
- Maintenir la flexibilité
L'avenir des deux projets
Section intitulée « L'avenir des deux projets »Les deux trajectoires ci-dessous ne sont pas des prédictions mais la lecture des mécanismes de décision déjà en place. Elles vous disent surtout où chercher l'information : la roadmap Vault se lit dans les annonces produit de HashiCorp, celle d'OpenBao dans les discussions publiques du dépôt.
Le pilotage est celui d'un produit commercial : les nouveautés arrivent d'abord dans l'édition payante, puis redescendent parfois vers l'édition Community. Attendez-vous à un écart CE/Enterprise qui se creuse plutôt qu'il ne se réduit.
- Développement continu par HashiCorp/IBM
- Roadmap définie par HashiCorp
- Nouvelles fonctionnalités en Enterprise d'abord
- Intégrations cloud renforcées
Sans édition payante à protéger, le projet n'a aucune raison de réserver une fonctionnalité : l'arrivée des namespaces dans la 2.3 en est l'illustration. Le revers est que les intégrations propriétaires, notamment côté fournisseurs cloud, dépendent de contributeurs bénévoles.
- Gouvernance Linux Foundation / OpenSSF
- Roadmap communautaire (GitHub Discussions)
- Focus sur les fonctionnalités "core" accessibles à tous
- Namespaces, auto-unseal amélioré, robustesse
À retenir
Section intitulée « À retenir »- Fonctionnellement proches : les deux solutions couvrent les mêmes cas d'usage fondamentaux
- Licence : Vault BSL (usage interne OK), OpenBao MPL 2.0 (open source pur)
- Namespaces : Vault Enterprise only, OpenBao inclus
- Maturité : Vault 10+ ans, OpenBao 2+ ans mais base solide
- Migration : CE → OpenBao simple, Enterprise → OpenBao complexe
- Décision : technique ET politique/juridique selon votre contexte