OpenBao : le fork open source de Vault

OpenBao est un coffre-fort de secrets open source, fork de HashiCorp Vault (v1.14.0), maintenu par la Linux Foundation via l’OpenSSF. Il offre une alternative 100% open source après le passage de Vault sous licence BSL.

Ce guide vous montre comment installer, configurer et utiliser OpenBao pour gérer vos secrets en production.

Compatibilité Vault

OpenBao maintient une compatibilité API avec Vault. Vos scripts, SDK et intégrations (Kubernetes, Terraform, Ansible) fonctionnent sans modification. La commande CLI passe de vault à bao.

Ce que vous allez apprendre

• Installer OpenBao v2.5 sur Linux
• Configurer les secrets engines : KV v2, Transit
• Mettre en place l’authentification : userpass, AppRole
• Écrire des policies HCL pour le contrôle d’accès granulaire
• Préparer une configuration production-ready

Prérequis

Hub : Gestion des secrets Comprendre les enjeux de la gestion des secrets

• Linux (x86_64 ou arm64)
• curl et jq installés
• Accès root ou sudo (pour le mode production)

OpenBao vs Vault : ce qui change

OpenBao est fonctionnellement équivalent à Vault Community Edition 1.14. Voici les différences principales :

Aspect	Vault CE	OpenBao
Licence	BSL 1.1 (restrictions commerciales)	MPL 2.0 (100% open source)
Mainteneur	HashiCorp	Linux Foundation / OpenSSF
CLI	vault	bao
Version actuelle	1.18+	2.5.1
Namespaces	Enterprise only	Inclus (depuis v2.3)
Compatibilité API	-	Compatible Vault 1.14

Glissez pour voir

Fonctionnalités Enterprise

Certaines fonctionnalités Vault Enterprise ne sont pas dans OpenBao : replication cross-datacenter, HSM seal providers propriétaires, support commercial. OpenBao ajoute cependant les namespaces gratuitement.

1. Installation

Téléchargement direct

1. Télécharger le binaire (v2.5.1, dernière version stable)

   VERSION="2.5.1"
   ARCH="x86_64"  # ou arm64
   
   curl -LO "https://github.com/openbao/openbao/releases/download/v${VERSION}/bao_${VERSION}_Linux_${ARCH}.tar.gz"

2. Extraire et installer

   tar xzf bao_${VERSION}_Linux_${ARCH}.tar.gz
   sudo mv bao /usr/local/bin/
   sudo chmod +x /usr/local/bin/bao

3. Vérifier l’installation

   bao version
   # OpenBao v2.5.1 (e546fae8cbfe95d8f36a351deb2cd23bfb94119e)

Via package manager (Fedora/RHEL)

# Activer EPEL si nécessaire
sudo dnf install -y epel-release

# Installer OpenBao
sudo dnf install -y openbao

Via container

# Docker Hub
docker pull openbao/openbao:2.5.1

# GitHub Container Registry
docker pull ghcr.io/openbao/openbao:2.5.1

# Quay.io
docker pull quay.io/openbao/openbao:2.5.1

2. Premier démarrage (mode dev)

Le mode dev est parfait pour apprendre. Il démarre un serveur en mémoire, non sécurisé, avec un token root prédéfini.

# Démarrer en mode développement
bao server -dev -dev-root-token-id="root"

Dans un autre terminal :

# Configurer l'environnement
export BAO_ADDR='http://127.0.0.1:8200'
export BAO_TOKEN='root'

# Vérifier le statut
bao status

Sortie attendue :

Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
Total Shares    1
Threshold       1
Version         2.5.1
Storage Type    inmem
HA Enabled      false

Mode dev = non sécurisé

Le mode dev stocke tout en mémoire, utilise HTTP non chiffré, et accepte un token root en clair. Ne jamais l’utiliser en production.

3. Secrets Engine : KV v2

Le secrets engine KV v2 stocke des secrets avec versioning automatique.

Écrire un secret

# Stocker des credentials
bao kv put secret/demo \
    username="admin" \
    password="SuperSecret123"

Sortie :

== Secret Path ==
secret/data/demo

======= Metadata =======
Key                Value
---                -----
created_time       2026-03-16T13:16:20.324983703Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            1

Lire un secret

# Lire la dernière version
bao kv get secret/demo

# Sortie JSON (pour scripts)
bao kv get -format=json secret/demo | jq -r '.data.data.password'

Versioning

# Mettre à jour le secret (crée version 2)
bao kv put secret/demo \
    username="admin" \
    password="NewPassword456"

# Lire une version spécifique
bao kv get -version=1 secret/demo

Supprimer un secret

# Soft delete (récupérable)
bao kv delete secret/demo

# Hard delete (définitif)
bao kv destroy -versions=1,2 secret/demo

# Supprimer toutes les métadonnées
bao kv metadata delete secret/demo

4. Secrets Engine : Transit (chiffrement as a service)

Transit permet de chiffrer/déchiffrer des données sans exposer les clés.

Activer Transit

bao secrets enable transit

Créer une clé de chiffrement

bao write -f transit/keys/my-app-key

Chiffrer des données

# Les données doivent être en base64
bao write transit/encrypt/my-app-key \
    plaintext=$(echo "données sensibles" | base64)

Sortie :

Key            Value
---            -----
ciphertext     vault:v1:5/94SlpHWje32JEfqYZjXEe32FL0...
key_version    1

Déchiffrer

bao write transit/decrypt/my-app-key \
    ciphertext="vault:v1:5/94SlpHWje32JEfqYZjXEe32FL0..."

# Le plaintext retourné est en base64

Rotation de clés

Vous pouvez effectuer une rotation de la clé sans re-chiffrer les données existantes. OpenBao conserve les anciennes versions pour déchiffrer.

bao write -f transit/keys/my-app-key/rotate

5. Authentification : userpass

La méthode userpass permet une authentification par identifiant/mot de passe, utile pour les développeurs et les tests.

Activer userpass

bao auth enable userpass

Créer un utilisateur

bao write auth/userpass/users/devuser \
    password="devpassword" \
    policies="default"

Se connecter

# Unset le token root d'abord
unset BAO_TOKEN

# Login
bao login -method=userpass \
    username=devuser \
    password=devpassword

Sortie :

Success! You are now authenticated.

Key                    Value
---                    -----
token                  s.15Wjnl3DVKulHTuNAyrSuyvi
token_accessor         u9dKTGCSPnWIPJeHVK6JHiyf
token_duration         768h
token_renewable        true
token_policies         ["default"]

6. Authentification : AppRole (pour CI/CD)

AppRole est la méthode recommandée pour les applications et pipelines CI/CD. Elle utilise un couple role_id + secret_id.

Activer AppRole

export BAO_TOKEN='root'  # Revenir en root
bao auth enable approle

Créer un rôle

bao write auth/approle/role/my-app \
    secret_id_ttl=10m \
    token_num_uses=10 \
    token_ttl=20m \
    token_max_ttl=30m \
    secret_id_num_uses=1 \
    policies="dev-policy"

Obtenir les credentials

# Le role_id est stable (stocké dans la config)
bao read auth/approle/role/my-app/role-id
# role_id    fce7ab03-5449-e1c5-e102-5c2b90b3e7b0

# Le secret_id est éphémère (généré à la demande)
bao write -f auth/approle/role/my-app/secret-id
# secret_id  4bb62b7c-8deb-0781-4b7b-854e479483f2

Login avec AppRole

bao write auth/approle/login \
    role_id="fce7ab03-5449-e1c5-e102-5c2b90b3e7b0" \
    secret_id="4bb62b7c-8deb-0781-4b7b-854e479483f2"

Secret ID à usage unique

Avec secret_id_num_uses=1, chaque secret_id ne peut servir qu’une seule fois. C’est la configuration recommandée pour les pipelines CI/CD.

7. Policies HCL

Les policies définissent qui peut accéder à quoi. Elles utilisent le format HCL.

Syntaxe de base

dev-policy.hcl

# Lecture/écriture sur secret/data/dev/*
path "secret/data/dev/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

# Lecture seule sur les métadonnées
path "secret/metadata/dev/*" {
  capabilities = ["list", "read"]
}

# Interdire l'accès à secret/data/prod/*
path "secret/data/prod/*" {
  capabilities = ["deny"]
}

Capabilities disponibles

Capability	HTTP Verb	Description
create	POST	Créer si n’existe pas
read	GET	Lire
update	POST/PUT	Modifier
delete	DELETE	Supprimer
list	LIST	Lister les clés
sudo	-	Opérations privilégiées
deny	-	Refuser explicitement

Glissez pour voir

Appliquer une policy

# Créer la policy
bao policy write dev-policy dev-policy.hcl

# Lister les policies
bao policy list

# Lire une policy
bao policy read dev-policy

Assigner à un utilisateur

bao write auth/userpass/users/devops \
    password="devopspass" \
    policies="dev-policy"

8. Configuration production

Pour la production, créez un fichier config.hcl :

/etc/openbao/config.hcl

ui = true

# Storage avec Raft (intégré, recommandé)
storage "raft" {
  path    = "/var/lib/openbao/data"
  node_id = "node1"
}

# Listener HTTPS (TLS obligatoire en prod !)
listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_cert_file = "/etc/openbao/tls/server.crt"
  tls_key_file  = "/etc/openbao/tls/server.key"
}

# Addresses
api_addr     = "https://openbao.example.com:8200"
cluster_addr = "https://openbao.example.com:8201"

# Sécurité
disable_mlock = false  # false si possible (performance)
log_level     = "info"

Démarrer en production

# Créer les répertoires
sudo mkdir -p /var/lib/openbao/data
sudo mkdir -p /etc/openbao/tls
sudo chown -R openbao:openbao /var/lib/openbao

# Démarrer
bao server -config=/etc/openbao/config.hcl

Initialisation

# Initialiser (une seule fois)
bao operator init -key-shares=5 -key-threshold=3

Sauvegardez les clés !

L’initialisation génère des unseal keys et un root token. Sans eux, impossible de déverrouiller ou administrer OpenBao. Stockez-les de manière sécurisée et séparée.

Unseal

# Répéter avec 3 clés différentes (threshold=3)
bao operator unseal <key1>
bao operator unseal <key2>
bao operator unseal <key3>

9. Fonctionnalités OpenBao 2.5

La version 2.5 apporte plusieurs améliorations notables :

• Horizontal Read Scalability : les nœuds standby peuvent servir les lectures, améliorant les performances
• Distribution de plugins OCI : téléchargement automatique de plugins depuis des registres de conteneurs
• OIDC Provider Client Credentials : nouveau flow pour l’OIDC
• Audit HTTP : webhook pour les événements d’audit
• Namespaces (depuis 2.3) : isolation multi-tenant sans licence Enterprise

À retenir

1. OpenBao = Vault open source (MPL 2.0), maintenu par Linux Foundation
2. Compatibilité API avec Vault 1.14 — migration transparente
3. KV v2 pour les secrets avec versioning
4. Transit pour le chiffrement as a service
5. AppRole pour l’authentification CI/CD
6. Policies HCL pour le contrôle d’accès granulaire
7. Namespaces inclus (vs Enterprise chez HashiCorp)

Migration depuis Vault

Si vous migrez depuis Vault :

1. Changez vault en bao dans vos scripts
2. Changez VAULT_* en BAO_* pour les variables d’environnement
3. Testez vos intégrations — l’API est compatible

Prochaines étapes

Cycle de vie d'un secret Génération, rotation, révocation, audit

Hub : Gestion des secrets Vue d'ensemble des pratiques

×

📖 Voir la documentation →