Déployer Vault HA en production sur Hetzner avec Raft storage — tutoriel 2026

📍 Article principal : Vault Associate — guide complet. Ce tutoriel déploie un cluster Vault HA en production sur trois VPS Hetzner avec Raft storage, unsealing automatique et audit logs.

Vault en production exige une architecture haute disponibilité. Une instance unique tombe avec son serveur — perte temporaire d’accès à tous les secrets paralyse l’organisation. La solution : un cluster Vault à trois nœuds avec storage backend Raft intégré, qui réplique automatiquement les données entre nœuds et tolère la perte d’un nœud. Ce tutoriel guide pas à pas le déploiement complet : provisioning des trois VPS, installation Vault, configuration Raft, initialisation et unsealing, vérification HA, configuration des audit logs, automatisation de l’unseal au reboot.

Prérequis

• Trois VPS Hetzner CX22 (2 vCPU, 4 Go RAM, 40 Go SSD) — environ 15 EUR par mois total
• Network Hetzner privé entre les trois VPS
• Domaine avec sous-domaines vault01/vault02/vault03 pointés vers les IPs publiques
• Notions Linux administration et SSH
• Niveau : avancé
• Temps estimé : 4 à 5 heures

Étape 1 — Provisionner les VPS et préparer le réseau

Provisionner les trois VPS avec Ubuntu 24.04 LTS. Les nommer explicitement : vault01, vault02, vault03. Ajouter une clé SSH commune pour faciliter l’administration. Créer un Network Hetzner avec la plage 10.0.0.0/16 et attacher les trois VPS — chaque nœud reçoit une IP secondaire 10.0.0.x sur ce network privé. Cette IP servira pour la communication Raft entre les nœuds, plus rapide et plus sécurisée que la communication par IP publique.

Configurer un firewall Hetzner qui autorise le port 8200 (API Vault) et 8201 (cluster Raft) entre les trois nœuds via leurs IPs privées, et le port 8200 publique pour les clients. Pour la sécurité maximale, restreindre le port 8200 public uniquement aux IPs des bastions et des serveurs CI/CD autorisés. Configurer aussi le hostname dans /etc/hosts sur chaque nœud pour la résolution croisée — précaution si le DNS interne tombe.

Étape 2 — Installer Vault sur les trois nœuds

Sur les trois nœuds, ajouter le dépôt officiel HashiCorp et installer Vault. La version recommandée en 2026 est la 1.17 LTS qui apporte des améliorations majeures sur les performances Raft et la stabilité de l’unsealing. Verrouiller la version pour éviter les upgrades involontaires.

wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor | sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install vault=1.17.* -y
sudo apt-mark hold vault

Créer le dossier /opt/vault/data qui contiendra le storage Raft, attribuer les bonnes permissions à l’utilisateur vault créé par le package. Créer aussi /var/log/vault pour les audit logs avec permissions adaptées. Cette préparation initiale évite les erreurs de permissions au premier démarrage.

Étape 3 — Configurer Vault avec Raft sur le premier nœud

Sur vault01, créer le fichier /etc/vault.d/vault.hcl avec la configuration. Trois sections clés : storage Raft avec le path local et l’identifiant de nœud, listener TCP avec TLS, cluster_addr pour la communication inter-nœuds.

storage "raft" {
  path    = "/opt/vault/data"
  node_id = "vault01"
}

listener "tcp" {
  address       = "0.0.0.0:8200"
  cluster_address = "10.0.0.2:8201"
  tls_disable   = false
  tls_cert_file = "/opt/vault/tls/vault.crt"
  tls_key_file  = "/opt/vault/tls/vault.key"
}

api_addr = "https://vault01.masociete.sn:8200"
cluster_addr = "https://10.0.0.2:8201"
ui = true

Pour les certificats TLS, générer un certificat Let’s Encrypt sur chaque nœud avec certbot, ou utiliser des certificats internes signés par une CA d’organisation. Démarrer Vault sur vault01 avec systemctl start vault. Vérifier le statut : systemctl status vault doit afficher active (running).

Étape 4 — Initialiser et unseal le cluster

Vault au démarrage est en état uninitialized et sealed. L’initialisation génère les unseal keys et le root token. Sur vault01 :

export VAULT_ADDR=https://vault01.masociete.sn:8200
vault operator init -key-shares=5 -key-threshold=3
# Sortie : 5 unseal keys + initial root token
# CONSERVER ces clés dans des coffres séparés gérés par 5 personnes différentes

vault operator unseal <key1>
vault operator unseal <key2>
vault operator unseal <key3>
# Vault est maintenant unsealed

Les unseal keys doivent être distribuées entre 5 personnes différentes (PDG, DSI, RSSI, etc.) et conservées dans des coffres séparés. Les 3 keys nécessaires à l’unseal demandent 3 personnes présentes : discipline qui prévient les abus de pouvoir individuel et garantit la continuité même en cas de départ d’un détenteur. Le root token doit être révoqué dès qu’un compte admin avec policy équivalente est créé — ne jamais utiliser le root token au quotidien.

Étape 5 — Joindre vault02 et vault03 au cluster

Sur vault02 et vault03, configuration similaire à vault01 mais avec node_id distinct. Démarrer le service. Sans initialisation locale (puisque le cluster existe déjà), joindre vault01 :

# Sur vault02
vault operator raft join https://vault01.masociete.sn:8200
vault operator unseal <key1>
vault operator unseal <key2>
vault operator unseal <key3>

# Vérifier sur vault01
vault operator raft list-peers
# Doit afficher les trois nœuds avec leur état

Répéter pour vault03. Le cluster est maintenant en HA avec quorum à 2 — la perte d’un nœud est tolérée sans interruption de service. Tester la HA en arrêtant volontairement vault01 (le leader) et observer la réélection automatique d’un nouveau leader parmi vault02 et vault03 en quelques secondes. Cette résilience est l’un des arguments commerciaux majeurs de Vault HA face aux solutions mono-nœud.

Étape 6 — Activer les audit logs

Les audit logs tracent chaque opération Vault (lecture, écriture, suppression de secrets, authentification, modification de policy). Sans audit logs, aucune traçabilité — non négociable en production. Activer le device file :

vault audit enable file file_path=/var/log/vault/audit.log
vault audit list
# Confirme l'activation

Les audit logs partent ensuite vers un système central (Loki, Elasticsearch, Splunk) via Promtail ou Filebeat. Configurer aussi la rotation logrotate pour éviter la saturation du disque local. Pour les organisations soumises à conformité stricte (banques, finance), l’export quotidien des audit logs vers un S3 chiffré write-only constitue une preuve immuable utilisable en cas de contrôle réglementaire.

Étape 7 — Auto-unseal pour la résilience

Au reboot d’un nœud, Vault démarre en état sealed et nécessite l’unseal manuel — opération qui réveille les détenteurs des unseal keys et ralentit la reprise. Solution : auto-unseal via cloud KMS qui chiffre la master key avec un service externe et la déverrouille automatiquement. Options en 2026 : AWS KMS, GCP KMS, Azure Key Vault, et Vault Transit (un autre Vault qui sert de KMS).

Pour les déploiements souverains qui veulent éviter les KMS étrangers, Vault Transit permet de configurer un Vault dédié auto-hébergé localement comme service de KMS pour les autres clusters Vault. Cette architecture imbriquée est devenue le standard chez les organisations qui veulent autonomie totale tout en bénéficiant de l’auto-unseal. La configuration tient en quelques lignes dans le fichier vault.hcl du cluster cible.

Sauvegardes et disaster recovery

Le storage Raft est durable mais les snapshots offrent une protection supplémentaire contre les corruptions logiques (bug applicatif qui supprime des secrets). Configurer un snapshot quotidien automatique via cron qui exécute vault operator raft snapshot save /backup/vault-$(date +%F).snap, encrypte le snapshot avec age ou GPG, l’archive vers un bucket S3 chiffré. Conserver 30 jours de snapshots quotidiens, 12 mois de snapshots mensuels — équilibre entre coût stockage et capacité de restauration historique.

Tester périodiquement la restauration sur un cluster bac à sable : démarrer un nouveau cluster vide, restaurer le snapshot avec vault operator raft snapshot restore, valider que les secrets attendus sont présents, vérifier les policies et auth methods. Cette discipline transforme une assurance théorique en sécurité opérationnelle réelle. Documenter le RTO réel mesuré : typiquement 30 à 60 minutes pour un cluster de taille PME.

Monitoring et alerting

Vault expose des métriques Prometheus via l’endpoint /v1/sys/metrics. Configurer Prometheus pour scrapper ces métriques et Grafana pour les visualiser. Métriques essentielles à surveiller : nombre de tokens actifs, latence des requêtes, taux d’erreur, état Raft (leader/follower par nœud), utilisation mémoire et CPU. Le dashboard officiel HashiCorp pour Grafana (ID 12904) couvre l’essentiel.

Configurer des alertes critiques : cluster non quorum (deux nœuds tombent), Vault sealed (auto-unseal échoue), latence p99 supérieure à 1 seconde, audit logs en erreur (disque plein). Ces alertes partent via Alertmanager vers PagerDuty, OpsGenie, ou un simple webhook Slack/Telegram. Pour les organisations critiques, une astreinte 24/7 avec rotation hebdomadaire prend en charge ces alertes.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Pour les déploiements souverains au Sénégal ou en Côte d’Ivoire, Wagaden Cloud et Sonatel Cloud proposent des VPS qui hébergent confortablement un cluster Vault HA. La latence réseau entre datacenters locaux reste largement compatible avec les exigences Raft. Pour les déploiements multi-pays (PME présente au Sénégal et en Côte d’Ivoire), déployer un cluster avec deux nœuds locaux et un nœud distant constitue une excellente résilience régionale.

Mises à jour et opérations courantes

HashiCorp publie une version mineure Vault tous les trois mois et des correctifs de sécurité plus fréquents. La procédure de mise à jour rolling sur cluster HA tient en cinq étapes par nœud : arrêter le service, mettre à jour le package, redémarrer, attendre le rejoin Raft, valider l’état avant de passer au nœud suivant. Aucune interruption de service côté clients si la procédure est suivie correctement.

Tester systématiquement les mises à jour majeures (1.x → 2.x quand elle sortira) sur un environnement bac à sable identique. Documenter dans un journal d’opérations chaque mise à jour avec version source, version cible, problèmes rencontrés. Cette traçabilité simplifie radicalement les diagnostics futurs et constitue une preuve de diligence opérationnelle valorisée par les audits clients institutionnels exigeants.

Performances et tuning

Vault tient une charge significative sur les VPS modestes. Sur un cluster CX22 trois nœuds, attendre 1 000 à 2 000 opérations par seconde sur des secrets KV. Pour les charges plus lourdes, monter en CCX13 (4 vCPU, 16 Go RAM) qui pousse à 5 000 ops/sec. Le bottleneck typique reste la latence Raft entre nœuds — pour réduire, choisir des datacenters géographiquement proches.

Pour optimiser les performances, configurer le cache Vault qui réduit drastiquement les appels au storage backend pour les secrets fréquemment lus. Activer aussi la performance replication (Enterprise uniquement) qui distribue la charge en lecture sur plusieurs clusters géographiquement séparés. Pour la majorité des PME, le cluster trois nœuds par défaut suffit largement — l’investissement dans la performance replication ne se justifie qu’au-delà de 10 000 utilisateurs concurrents.

Sécurité opérationnelle au quotidien

Au-delà du déploiement initial, plusieurs disciplines sécuritaires quotidiennes maintiennent Vault sain. Premier : rotation périodique des unseal keys et du root token (annuelle minimum). Deuxième : revue trimestrielle des policies actives, suppression des comptes inactifs depuis plus de 90 jours, audit des permissions accordées. Troisième : vérification mensuelle que les audit logs sont effectivement collectés et exploitables — un audit log dont personne ne lit le contenu est une fausse sécurité.

Quatrième discipline : tests de pénétration annuels par un consultant externe qui valide la posture sécuritaire. Le coût de l’audit (1 à 3 millions XOF selon la taille du cluster) reste un excellent investissement face aux conséquences potentielles d’une compromission. Cinquième : formation continue de l’équipe technique aux nouveautés Vault et aux menaces émergentes. La sécurité est un domaine en évolution constante qui exige une veille active.

Intégration avec les autres outils

Vault s’intègre avec l’ensemble de la stack DevOps moderne. Premier : Terraform via le provider Vault qui permet de lire les secrets dynamiquement pendant le plan/apply, sans jamais les stocker dans le state. Deuxième : Kubernetes via Vault Agent Injector qui injecte automatiquement les secrets dans les pods sous forme de fichiers ou de variables d’environnement.

Troisième : GitLab CI et GitHub Actions via les Vault Secrets actions officielles qui authentifient le pipeline et récupèrent les secrets nécessaires au build et au déploiement. Quatrième : applicatifs via le Vault Agent qui s’authentifie au démarrage et expose les secrets au format souhaité (fichier, variable env, template). Ces intégrations transforment Vault de stockage isolé en pierre angulaire de toute la chaîne CI/CD sécurisée.

Pratiques d’opération matures

Pour les organisations qui veulent industrialiser leur opération Vault, plusieurs pratiques distinguent les déploiements professionnels. Premier : Infrastructure-as-Code complète du cluster — tout le déploiement Vault est géré par Terraform avec modules dédiés. Cette approche permet la reproductibilité et facilite les disaster recovery sur nouvelle infrastructure.

Deuxième : gitops pour les configurations Vault — policies, auth methods, secrets engines déclarés dans un dépôt Git, appliqués automatiquement par un pipeline CI qui synchronise l’état Vault avec le code Git. Cette discipline transforme Vault d’un état mutable opaque en système déclaratif auditable. Troisième : tests automatisés des policies via le simulateur Sentinel pour valider que les règles font effectivement ce qu’on attend.

Cette discipline opérationnelle complète constitue le fondement sur lequel reposent les déploiements Vault en production qui durent dans le temps sans incidents majeurs ni dette technique accumulée.

Pour aller plus loin

🔝 Retour à l’article principal : Vault Associate. Documentation Vault Raft : developer.hashicorp.com/vault/docs/configuration/storage/raft, guide HA officiel : developer.hashicorp.com/vault/docs/concepts/ha.

Le déploiement Vault HA constitue le rite de passage vers la maîtrise opérationnelle réelle de l’outil. Cette pratique sur cluster réel renforce drastiquement la compréhension par rapport à la simple exposition mode dev. Pour les apprenants ITSkillsCenter qui visent la certification, investir une semaine de pratique sur ce cluster construit l’aisance opérationnelle qui distingue les candidats sérieux des autres lors de l’examen.