OpenBao 2026 : guide complet pour déployer un cluster de gestion des secrets sur Linux (Raft, auto-unseal, PKI)
OpenBao 2.5, le gestionnaire de secrets open source gouverné par la Linux Foundation, atteint la maturité production en 2026. Guide de déploiement cluster Raft 3 nœuds sur Linux, auto-unseal Transit, moteur PKI et durcissement systemd.
OpenBao 2.5 est le gestionnaire de secrets open source (MPL 2.0) gouverné par la Linux Foundation via l'OpenSSF, forké depuis HashiCorp Vault 1.14 et devenu en 2026 une alternative de niveau production pour les clusters Linux. Ce guide décrit, du point de vue d'un architecte sécurité, comment déployer OpenBao 2.5 (sorti le 4 février 2026) en cluster Raft à trois nœuds sur Linux, activer l'auto-unseal Transit, provisionner un moteur PKI et durcir le service systemd, en gardant toujours en tête la question qui compte : qu'est-ce qui casse en premier ?
OpenBao 2.5.0 (février 2026) inclut désormais les Namespaces et la scalabilité en lecture horizontale, fonctionnalités auparavant réservées à Vault Enterprise.
Le stockage intégré Raft est le seul backend recommandé : trois nœuds minimum, quorum à deux, pas de dépendance externe.
L'auto-unseal Transit (OpenBao-vers-OpenBao) est le pattern on-premise privilégié : un cluster « unseal-only » isolé sert de KMS logiciel.
Le rayon de souffle d'une compromission racine reste total. Le token racine doit être révoqué immédiatement après l'initialisation.
Sur Linux, désactiver le swap (ou le chiffrer via cryptswap), utiliser mlock et confiner le binaire bao derrière un service systemd durci.
Le moteur PKI permet d'émettre des certificats X.509 courts (TTL 24 h ou moins), rendant la révocation quasi obsolète et ancrant la stratégie mTLS.
Qu'est-ce qu'OpenBao et pourquoi en 2026 ?
OpenBao est un système de gestion de secrets, de certificats et de clés distribué, forké depuis HashiCorp Vault 1.14 lorsque HashiCorp est passé de la MPL 2.0 à la Business Source License 1.1 en août 2023. La Linux Foundation a annoncé le projet en décembre 2023, puis OpenBao a rejoint LF Edge en avril 2024 avant de migrer vers l'OpenSSF (Open Source Security Foundation) en juin 2025 en tant que projet sandbox. À la version 2.5.0 (février 2026), le projet compte environ 5 900 étoiles GitHub, 408 contributeurs et une cadence de publication trimestrielle.
Alors pourquoi en 2026 ? Parce que trois éléments viennent de basculer. D'abord, GitLab utilise OpenBao comme moteur natif de son Secrets Manager pour les pipelines CI/CD et siège au TSC. Ensuite, deux fournisseurs (Adfinis avec Secretz Enterprise, ControlPlane avec son propre offre) proposent depuis début 2026 un support commercial 24/7. Enfin, la fonctionnalité Namespaces (isolation multi-tenant, longtemps exclusive à Vault Enterprise) est désormais dans le tronc open source, ce qui change complètement l'équation économique pour les plateformes internes qui doivent héberger plusieurs équipes.
Concrètement, OpenBao fait cinq choses : (1) stocker des secrets statiques chiffrés (KV v2, avec historique de versions), (2) générer des secrets dynamiques éphémères (bases de données, cloud, PKI), (3) fournir du chiffrement-en-tant-que-service via le moteur Transit, (4) offrir une location (lease) et une révocation en cascade, et (5) authentifier des workloads via AppRole, JWT, Kubernetes ou certificats TLS.
OpenBao vs HashiCorp Vault : le tableau de décision
Au niveau des API et des moteurs de secrets, OpenBao 2.5 et Vault 2.0 (sorti le 13 avril 2026 sous IBM) sont, en 2026, quasi identiques : c'est la même architecture, la même CLI (renommée bao), les mêmes appels HTTP. La différence est stratégique, pas technique.
Dimension
OpenBao 2.5
HashiCorp Vault 2.0
Licence
MPL 2.0 (OSI open source)
BSL 1.1 (source-available)
Gouvernance
Linux Foundation / OpenSSF
IBM (depuis 2024)
Namespaces multi-tenant
Inclus dans l'open source
Enterprise uniquement
Scalabilité lecture horizontale
Incluse dans l'open source
Enterprise uniquement
Réplication DR / Performance
Non disponible
Enterprise uniquement
Intégration HSM
PKCS#11 (SoftHSM, TPM)
Enterprise + PKCS#11
Support commercial 24/7
Adfinis, ControlPlane
IBM
Étoiles GitHub (mi-2026)
≈ 5 900
≈ 33 400
La question à poser à votre juridique n'est pas « lequel est meilleur techniquement » mais « avons-nous une obligation contractuelle ou réglementaire d'utiliser du logiciel OSI-conforme ? ». Dans la finance régulée, le secteur public européen (CRA), et de plus en plus les acheteurs Fortune 500, la réponse est oui. Honnêtement, sur mes deux derniers audits chez des clients bancaires, c'est cette ligne-là qui a fait basculer le choix vers OpenBao. Pour un cadre plus large sur la conformité open source côté chaîne logicielle, voir notre article dédié à la sécurité de la chaîne d'approvisionnement logicielle et à la conformité CRA.
Modèle de menace : qu'est-ce qui casse en premier ?
Avant de taper la moindre commande, cartographiez le rayon de souffle. Un gestionnaire de secrets déplace le risque, il ne l'élimine pas : au lieu d'avoir cinquante secrets dispersés dans autant de configurations, vous avez un seul système qui, s'il tombe, entraîne l'indisponibilité de tout ce qui en dépend. Voici les quatre modes de défaillance qui réveillent mes équipes la nuit.
1. Perte des clés Shamir. Par défaut, l'initialisation génère 5 parts avec un seuil de 3. Si vous perdez trois parts (ou toutes en Shamir simple sans auto-unseal), les données chiffrées sur disque sont définitivement inaccessibles. La sauvegarde ne vous sauvera pas, car le snapshot est chiffré avec la même clé maître. Solution : distribuer les parts dans des coffres physiques ou HSM géographiquement séparés, jamais dans le même gestionnaire de mots de passe.
2. Compromission du token racine. Le token racine créé à l'initialisation contourne toutes les politiques. Il doit être révoqué (pas juste stocké) immédiatement après avoir créé un moteur d'authentification alternatif, typiquement AppRole pour les workloads et OIDC pour les humains.
3. Fuite mémoire via swap. OpenBao déchiffre les secrets en RAM. Si le noyau pagine cette RAM sur le swap non chiffré, un attaquant avec accès disque récupère les secrets en clair. Désactivez le swap (swapoff -a) ou chiffrez-le via /etc/crypttab et configurez disable_mlock = false.
4. Perte de quorum Raft. Un cluster à trois nœuds tolère la perte d'un nœud. Perdez-en deux simultanément et le cluster passe en lecture seule jusqu'à récupération manuelle via bao operator raft peers.json. Répartissez les nœuds sur trois zones de défaillance distinctes. (J'ai vu un cluster tomber parce que les trois VM étaient sur le même hyperviseur ESXi, tout le monde jurait le contraire.)
Préparer les nœuds Linux avant l'installation
Ce guide cible Debian 13, Ubuntu 24.04 LTS ou RHEL 10 / Rocky Linux 10. Le principe est le même partout : un utilisateur système dédié, aucun shell interactif, systèmes de fichiers séparés pour les données Raft, et capabilities Linux plutôt que root.
# Sur chacun des 3 nœuds (openbao-1, openbao-2, openbao-3)
sudo useradd --system --home /var/lib/openbao --shell /usr/sbin/nologin openbao
sudo mkdir -p /etc/openbao /var/lib/openbao/raft /var/log/openbao
sudo chown -R openbao:openbao /etc/openbao /var/lib/openbao /var/log/openbao
sudo chmod 750 /etc/openbao /var/lib/openbao
# Désactiver le swap (indispensable en production)
sudo swapoff -a
sudo sed -i '/\sswap\s/s/^/#/' /etc/fstab
# Autoriser mlock sans être root (au lieu de tourner le service en root)
sudo setcap cap_ipc_lock=+ep /usr/bin/bao
Récupérez le binaire depuis le dépôt officiel plutôt que le paquet distribution (souvent en retard d'une version mineure). Vérifiez systématiquement la signature Cosign publiée avec chaque release GitHub d'OpenBao :
BAO_VERSION="2.5.0"
curl -LO "https://github.com/openbao/openbao/releases/download/v${BAO_VERSION}/bao_${BAO_VERSION}_linux_amd64.tar.gz"
curl -LO "https://github.com/openbao/openbao/releases/download/v${BAO_VERSION}/bao_${BAO_VERSION}_SHA256SUMS"
sha256sum -c bao_${BAO_VERSION}_SHA256SUMS --ignore-missing
tar -xzf bao_${BAO_VERSION}_linux_amd64.tar.gz
sudo install -m 0755 bao /usr/bin/bao
bao version # OpenBao v2.5.0
Le pare-feu doit ouvrir uniquement les ports 8200 (API) et 8201 (Raft) entre les trois nœuds, jamais depuis l'extérieur. Si vous suivez déjà notre guide de durcissement nftables sur Linux, ajoutez une chaîne openbao-cluster filtrant strictement par adresse source.
Déployer un cluster Raft à trois nœuds
Le stockage intégré Raft est le seul backend recommandé en 2026 : Consul est déprécié comme backend principal, et les autres (etcd, MySQL) souffrent de contraintes de cohérence. Trois nœuds constituent le minimum pour un cluster HA (haute disponibilité), avec un quorum de deux. C'est le compromis classique entre tolérance aux pannes et coût.
Créez d'abord un certificat TLS pour chaque nœud (à minima, une CA interne signée par votre PKI existante ou step-ca). Puis, sur openbao-1, écrivez la configuration :
Répliquez ce fichier sur openbao-2 et openbao-3 en changeant node_id, cluster_addr, api_addr. Démarrez d'abord openbao-1, initialisez, puis démarrez les deux autres qui rejoindront automatiquement grâce à retry_join.
# Sur openbao-1 uniquement
sudo systemctl start openbao
export BAO_ADDR=https://127.0.0.1:8200
bao operator init \
-recovery-shares=5 \
-recovery-threshold=3 \
-format=json > /root/openbao-init.json
# Stockez les 5 recovery keys et le root_token dans 5 coffres séparés,
# puis SUPPRIMEZ ce fichier de /root immédiatement.
# Sur openbao-2 et openbao-3 : simple démarrage, ils rejoignent tout seuls
sudo systemctl start openbao
bao operator raft list-peers
À ce stade, si vous avez configuré l'auto-unseal Transit, les nœuds sont déjà déscellés. Sinon, chaque nœud demande trois parts Shamir au démarrage, ce qui est inacceptable en production.
Configurer l'auto-unseal Transit
L'auto-unseal résout le problème opérationnel : vous ne voulez pas qu'un opérateur humain se connecte à 3 h du matin pour taper trois clés Shamir après un redémarrage. Quatre options existent en 2026, toutes documentées dans les concepts de stockage intégré OpenBao :
Transit Seal : un OpenBao dédié « unseal-only ». Pattern on-premise recommandé.
Cloud KMS : AWS KMS, Azure Key Vault, GCP Cloud KMS. Simple si vous êtes déjà cloud.
PKCS#11 / TPM : SoftHSM ou vTPM 2.0 pour un ancrage matériel par nœud.
Static Key : clé AES-256 statique. Uniquement pour la démo ou les environnements air-gap avec rotation manuelle.
Le pattern Transit est celui que je recommande sur bare-metal. Sur un serveur isolé (idéalement dans un VLAN administratif séparé), déployez un unique OpenBao mono-nœud qui ne stocke aucun secret applicatif. Sa seule fonction est d'exposer une clé Transit qui déchiffre le seal du cluster de production.
# Sur le nœud unseal.internal (indépendant du cluster prod)
bao secrets enable transit
bao write -f transit/keys/openbao-prod-unseal type=aes256-gcm96
# Politique dédiée : uniquement encrypt/decrypt sur cette clé
cat > /tmp/unseal-policy.hcl <<'EOF'
path "transit/encrypt/openbao-prod-unseal" { capabilities = ["update"] }
path "transit/decrypt/openbao-prod-unseal" { capabilities = ["update"] }
EOF
bao policy write openbao-prod-unseal /tmp/unseal-policy.hcl
# Créer un token périodique (renouvelable indéfiniment) pour les 3 nœuds prod
bao token create -policy=openbao-prod-unseal -period=24h -orphan
Ce token est celui à mettre dans le bloc seal "transit" de la configuration prod. En cas de compromission d'un nœud prod, révoquez juste le token : le cluster continue avec les deux autres et vous en générez un nouveau. Le rayon de souffle est ainsi limité à un seul nœud plutôt qu'à l'ensemble des clés Shamir.
Provisionner le moteur PKI pour mTLS interne
Le moteur PKI d'OpenBao est probablement la fonctionnalité la plus sous-utilisée. Il génère dynamiquement des certificats X.509 avec une TTL configurable : 24 h, voire une heure. À TTL courte, la révocation devient largement obsolète, car un certificat compromis expire avant que la CRL n'ait le temps d'être distribuée.
# Activer le moteur PKI et créer une CA intermédiaire de 10 ans
bao secrets enable -path=pki_int pki
bao secrets tune -max-lease-ttl=87600h pki_int
# Émettre un CSR de CA intermédiaire, à faire signer par votre CA racine offline
bao write -format=json pki_int/intermediate/generate/internal \
common_name="LinuxSecureOps Intermediate CA" \
key_type=ec key_bits=384 \
| jq -r '.data.csr' > /tmp/pki_int.csr
# Signer /tmp/pki_int.csr avec la CA racine hors-ligne, puis :
bao write pki_int/intermediate/set-signed certificate=@/tmp/pki_int.crt
# Créer un rôle pour les services internes (TTL 24 h)
bao write pki_int/roles/internal-services \
allowed_domains="internal.linuxsecureops.com" \
allow_subdomains=true \
max_ttl="24h" \
key_type="ec" key_bits=384
# Un service qui a besoin d'un certif l'obtient en une commande :
bao write pki_int/issue/internal-services \
common_name="api.internal.linuxsecureops.com" \
ttl="24h"
Combinez ce moteur avec une politique AppRole : chaque service systemd démarre avec un role_id et un secret_id injectés via LoadCredential= de systemd, appelle OpenBao pour obtenir son certif, l'utilise pendant 24 h, puis recommence. Le rayon de souffle d'un certificat volé est ainsi de moins d'une journée. Pour la partie transport, cela complète parfaitement notre guide de durcissement SSH avec OpenSSH 10 et cryptographie post-quantique.
Durcir le service systemd d'OpenBao
Le binaire bao lui-même n'a pas besoin de la moitié des privilèges qu'un processus a par défaut. Utilisez systemd pour éliminer chirurgicalement les surfaces d'attaque. C'est la même logique que dans notre guide de durcissement des services systemd avec ProtectSystem.
Vérifiez le résultat avec systemd-analyze security openbao.service : viser un score sous 2.0 (« UNSAFE » → « OK »). Le point essentiel est CapabilityBoundingSet=CAP_IPC_LOCK : le processus peut appeler mlock() pour empêcher la pagination des secrets vers le swap, sans autre capability.
Audit, sauvegardes et observabilité
Un OpenBao sans audit devices est aveugle. Activez-en toujours au moins deux, pour que la perte d'un ne coupe pas la journalisation (OpenBao refuse d'écrire s'il ne peut pas auditer). Combinez un fichier local et un socket vers votre pipeline SIEM.
# Fichier local (rotation par logrotate)
bao audit enable file file_path=/var/log/openbao/audit.log
# Socket vers un collecteur syslog / Vector / Fluent Bit
bao audit enable socket \
address=127.0.0.1:9090 \
socket_type=tcp
Pour les sauvegardes, prenez un snapshot Raft chaque heure et répliquez-le vers un stockage objet chiffré côté client (age ou rclone crypt). Un snapshot contient toutes les données chiffrées : sans les recovery keys, il est inutile, mais avec elles, il permet la restauration complète. Traitez-le comme un secret racine.
bao operator raft snapshot save /var/backups/openbao-$(date -u +%Y%m%dT%H%M%SZ).snap
age -r "$(cat /etc/openbao/backup-age.pub)" \
-o /var/backups/openbao-latest.snap.age \
/var/backups/openbao-*.snap
rclone move /var/backups/openbao-latest.snap.age s3-cold:openbao-backups/
Côté métriques, activez l'endpoint Prometheus (bloc telemetry ci-dessus) et alertez sur trois signaux : (1) vault.core.unsealed à 0 sur un nœud, (2) latence P99 vault.core.handle_request supérieure à 200 ms, (3) échecs répétés sur vault.token.lookup, signe classique de balayage de tokens volés. Dans une mission récente, c'est ce troisième signal qui a détecté un token de service oublié dans un dépôt Git privé compromis.
Questions fréquentes
OpenBao est-il vraiment prêt pour la production en 2026 ?
Oui. La version 2.5.0 est stable, GitLab l'utilise en tant que backend natif de son Secrets Manager, deux fournisseurs (Adfinis, ControlPlane) offrent un support 24/7 commercial, et le TSC regroupe six organisations dont SAP et Wallix. Les seules fonctionnalités manquantes par rapport à Vault Enterprise sont la réplication DR/performance et certaines intégrations HSM propriétaires.
Comment migrer depuis HashiCorp Vault vers OpenBao sans coupure ?
Les données Vault jusqu'à la version 1.14 sont directement compatibles : un snapshot Raft Vault peut être restauré dans OpenBao. Pour les versions ultérieures, exportez les moteurs via vault kv get -format=json, réimportez avec bao kv put, puis basculez le DNS. Prévoyez une fenêtre pour la migration des politiques (syntaxe identique) et des configurations d'authentification.
Faut-il un HSM matériel pour OpenBao en production ?
Non, sauf obligation réglementaire (FIPS 140-3 niveau 2, PCI-DSS 4.0 pour certains scénarios). Le pattern Transit auto-unseal, correctement isolé et sauvegardé, offre un niveau de sécurité suffisant pour la majorité des cas. Ajoutez PKCS#11/vTPM si vous devez ancrer les clés à du matériel spécifique par nœud.
Que se passe-t-il si le nœud d'auto-unseal Transit tombe ?
Le cluster de production continue de fonctionner tant qu'aucun nœud ne redémarre. Un redémarrage force le nœud concerné à contacter le service Transit ; sans lui, le nœud reste scellé. En pratique, redondez le nœud Transit lui-même (RFC #1830 en cours propose l'auto-seal + Shamir de secours comme mécanisme natif).
Quelle différence entre KV v1 et KV v2 dans OpenBao ?
KV v2 conserve un historique de versions par clé (par défaut 10 versions) et permet le soft-delete avec purge différée : un secret supprimé par erreur peut être restauré. KV v1 est un simple magasin clé-valeur sans versionnement. En production, activez toujours KV v2, car les frais de stockage sont négligeables et l'historique sauve régulièrement d'un déploiement raté.
