Opérer Vault en production : guide complet

Opérer Vault en production va bien au-delà de l’installation. Ce guide couvre les aspects opérationnels essentiels : dimensionnement, haute disponibilité, monitoring, sauvegardes, maintenance et troubleshooting.

Ce guide ne remplace pas un test de charge

Les recommandations de dimensionnement et d’architecture présentées ici sont des ordres de grandeur basés sur l’expérience terrain. Chaque environnement est différent. Validez votre configuration par des tests de charge avant la mise en production.

Prérequis

Ce guide suppose que vous avez déjà :

Installé Vault Installation et premier démarrage

Le scellement, vous le maîtrisez ? Mécanismes de seal/unseal

Ce que vous allez apprendre

• Dimensionner un cluster selon votre charge
• Configurer un cluster HA avec Raft
• Mettre en place le monitoring Prometheus/Grafana
• Automatiser les sauvegardes Raft
• Effectuer les opérations de maintenance
• Diagnostiquer les problèmes courants
• Appliquer la checklist de sécurité production

Sources de données critiques

Avant d’entrer dans le détail, les docs officielles identifient trois piliers pour l’observabilité d’un cluster Vault :

Source	Contenu	Usage
Audit logs	Toutes les requêtes authentifiées	Sécurité, conformité, forensics
Operational logs	Événements système, erreurs	Troubleshooting, alertes
Telemetry	Métriques Prometheus/StatsD	Monitoring, capacity planning

Glissez pour voir

Ces trois sources sont complémentaires. Un cluster production doit les activer toutes.

Dimensionnement du cluster

Combien de nœuds ?

Configuration	Nœuds	Tolérance pannes	Usage
Développement	1	0	Tests, POC
Production	3	1	Base de prod la plus courante
Tolérance renforcée	5	2	Besoin de résilience accrue
Cas spécifiques	7	3	À justifier selon le contexte

Glissez pour voir

Pourquoi des nombres impairs ?

Le consensus Raft nécessite une majorité (quorum). Avec 3 nœuds, 2 doivent être disponibles. Avec 5 nœuds, 3 doivent l’être. Un nombre pair n’améliore pas la tolérance aux pannes mais ajoute de la complexité.

3 nœuds suffit souvent

Évitez le nœud unique pour un usage réellement production. Un cluster Raft à 3 nœuds est la configuration la plus courante et offre une bonne balance entre résilience et simplicité opérationnelle.

Ordres de grandeur des ressources

Le tableau suivant donne des points de départ, pas des valeurs définitives. Le dimensionnement réel dépend de votre mix de charge.

Charge indicative	CPU	RAM	Stockage	IOPS
Légère (< 100 req/s)	2 vCPU	4 GB	25 GB SSD	1000
Moyenne (100-500 req/s)	4 vCPU	8 GB	50 GB SSD	3000
Élevée (500-2000 req/s)	8 vCPU	16 GB	100 GB SSD	10000
Très élevée (> 2000 req/s)	16 vCPU	32 GB	200 GB SSD	15000+

Glissez pour voir

Validez par test de charge

Ces valeurs sont des ordres de grandeur. HashiCorp recommande le tuning et l’observation de votre charge réelle plutôt que des tableaux fixes. Testez avant de déployer.

Facteurs de dimensionnement

Facteur	Impact
Mix lecture/écriture	Les écritures impactent tous les nœuds (réplication)
Transit / PKI	Opérations crypto = CPU intensif
Secrets dynamiques	Plus gourmand (connexions DB, appels API)
Audit logging	I/O significatif selon le volume
Nombre de secrets	Plus de secrets = plus de stockage et RAM

Glissez pour voir

Points d’attention :

• Stockage : SSD obligatoire, NVMe recommandé pour les charges élevées
• IOPS : souvent le goulot d’étranglement
• Réseau : latence < 10ms entre nœuds du cluster
• RAM : Vault garde beaucoup en mémoire pour la performance

Architecture haute disponibilité

Cluster Raft 3 nœuds

Configuration Raft multi-nœuds

vault.hcl (nœud 1) :

cluster_name = "vault-prod"
cluster_addr = "https://vault-1.internal:8201"
api_addr     = "https://vault-1.internal:8200"

storage "raft" {
  path    = "/opt/vault/data"
  node_id = "vault-1"

  retry_join {
    leader_api_addr = "https://vault-2.internal:8200"
  }
  retry_join {
    leader_api_addr = "https://vault-3.internal:8200"
  }
}

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

seal "awskms" {
  region     = "eu-west-1"
  kms_key_id = "alias/vault-unseal"
}

# Telemetry pour Prometheus
telemetry {
  prometheus_retention_time = "30s"
  disable_hostname          = true
}

Adaptez pour chaque nœud :

• cluster_addr et api_addr avec l’adresse du nœud
• node_id unique
• retry_join vers les autres nœuds

Rejoindre un cluster existant

1. Préparer le nouveau nœud avec la même configuration (en adaptant node_id, cluster_addr, api_addr)

2. Démarrer Vault sur le nouveau nœud :

   sudo systemctl start vault

3. Le nœud contacte les leaders potentiels via retry_join

4. Vérifier le statut du cluster :

   vault operator raft list-peers

   Sortie attendue :

   Node       Address                    State       Voter
   ----       -------                    -----       -----
   vault-1    vault-1.internal:8201      leader      true
   vault-2    vault-2.internal:8201      follower    true
   vault-3    vault-3.internal:8201      follower    true

Comportement du join selon le seal

Le processus de join dépend du mécanisme de seal :

• Auto-unseal (KMS) : le nouveau nœud rejoint et s’unseal automatiquement
• Shamir : le nouveau nœud reçoit un challenge et doit être déscellé avec les unseal keys du cluster leader pour finaliser l’adhésion

Avec Shamir, le join n’est pas “magique” — une intervention manuelle est nécessaire.

Load balancer et health checks

Le load balancer doit distribuer le trafic et vérifier la santé des nœuds.

Codes retour de /v1/sys/health

État du nœud	Code par défaut	Avec standbyok=true
Active (leader)	200	200
Standby	429	200
Performance standby (Enterprise)	473	200
Sealed	503	503
Uninitialized	501	501

Glissez pour voir

standbyok=true

Le paramètre standbyok=true fait répondre les standby avec le code de l’actif (200). C’est indispensable pour que le load balancer distribue le trafic sur tous les nœuds, pas seulement le leader.

Exemple HAProxy :

frontend vault_front
    bind *:443 ssl crt /etc/haproxy/certs/vault.pem
    default_backend vault_back

backend vault_back
    balance roundrobin
    option httpchk GET /v1/sys/health?standbyok=true
    http-check expect status 200

    server vault-1 vault-1.internal:8200 check ssl verify none
    server vault-2 vault-2.internal:8200 check ssl verify none
    server vault-3 vault-3.internal:8200 check ssl verify none

Points clés :

• Health check sur /v1/sys/health?standbyok=true
• Session persistence non requise (stateless)
• Les standby peuvent servir les requêtes de lecture

Monitoring et alertes

Métriques Prometheus

Vault expose des métriques au format Prometheus sur /v1/sys/metrics.

Activer les métriques dans vault.hcl :

telemetry {
  prometheus_retention_time = "30s"
  disable_hostname          = true
}

Policy pour accéder aux métriques :

path "sys/metrics" {
  capabilities = ["read", "list"]
}

read ET list

La capability list est nécessaire en plus de read pour que Prometheus puisse scraper les métriques correctement.

Scrape config Prometheus :

scrape_configs:
  - job_name: 'vault'
    metrics_path: '/v1/sys/metrics'
    params:
      format: ['prometheus']
    scheme: https
    tls_config:
      insecure_skip_verify: true  # Ou configurez le CA
    bearer_token_file: /etc/prometheus/vault-token
    static_configs:
      - targets:
        - 'vault-1.internal:8200'
        - 'vault-2.internal:8200'
        - 'vault-3.internal:8200'

Métriques utiles à surveiller

Ce tableau présente des métriques utiles en priorité, pas des seuils absolus. Adaptez les valeurs à votre contexte.

Métrique	Alerte suggérée	Signification
vault_core_unsealed	== 0 pendant > 1min	Vault est scellé
vault_core_active	Aucun nœud = 1	Pas de leader
vault_raft_leader	Changements fréquents	Instabilité cluster
vault_raft_peers	< attendu	Nœuds déconnectés
vault_audit_log_request_failure	> 0	Audit en échec (critique)
vault_runtime_alloc_bytes	Croissance continue	Pression mémoire
vault_token_count	À observer	Fuite potentielle de tokens
vault_expire_num_leases	Croissance rapide	Leases non révoqués

Glissez pour voir

Interpréter selon l'usage

Une croissance de vault_token_count peut être normale si votre charge augmente. Ces métriques doivent être corrélées avec votre activité métier. Consultez la référence complète des métriques HashiCorp pour plus de détails.

Alertes Prometheus recommandées

groups:
  - name: vault
    rules:
      - alert: VaultSealed
        expr: vault_core_unsealed == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Vault est scellé sur {{ $labels.instance }}"

      - alert: VaultNoLeader
        expr: sum(vault_core_active) == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Aucun leader Vault actif"

      - alert: VaultRaftPeersLow
        expr: vault_raft_peers < 3
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Cluster Vault dégradé - {{ $value }} nœuds"

      - alert: VaultAuditFailure
        expr: rate(vault_audit_log_request_failure[5m]) > 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Échec d'écriture des logs d'audit"

      - alert: VaultHighMemory
        expr: vault_runtime_alloc_bytes / (1024*1024*1024) > 12
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Vault utilise {{ $value | humanize }}GB de RAM"

Dashboard Grafana

La communauté propose des dashboards Grafana pour Vault, notamment : Vault Metrics Dashboard

Panneaux recommandés :

• Statut du cluster (leader, peers)
• Requêtes par seconde
• Latence des opérations
• Utilisation mémoire et CPU
• Audit log rate
• Token/Lease counts

Sauvegardes et restauration

Types de sauvegardes

Type	Contenu	Disponibilité
Snapshot Raft manuel	Données complètes	Toutes éditions
Snapshot Raft automatique	Données complètes, planifié	Enterprise
Export secrets	Secrets spécifiques	Toutes éditions

Glissez pour voir

Snapshots automatiques Enterprise

Vault Enterprise permet de configurer des snapshots automatiques vers stockage local ou cloud (S3, GCS, Azure). En Community Edition, vous devez automatiser les snapshots manuels via script et cron.

Automatiser les snapshots Raft (CE)

1. Créer une policy de backup :

   path "sys/storage/raft/snapshot" {
     capabilities = ["read"]
   }

2. Créer un token dédié :

   vault token create \
     -policy=backup \
     -ttl=8760h \
     -display-name="backup-automation"

3. Script de backup (/opt/vault/scripts/backup.sh) :

   #!/bin/bash
   set -euo pipefail
   
   BACKUP_DIR="/opt/vault/backups"
   RETENTION_DAYS=30
   DATE=$(date +%Y%m%d-%H%M%S)
   BACKUP_FILE="${BACKUP_DIR}/vault-snapshot-${DATE}.snap"
   
   # Vérifier que Vault est accessible
   vault status > /dev/null 2>&1 || {
     echo "ERROR: Vault inaccessible"
     exit 1
   }
   
   # Créer le snapshot
   vault operator raft snapshot save "${BACKUP_FILE}"
   
   # Vérifier l'intégrité
   if [[ -f "${BACKUP_FILE}" && -s "${BACKUP_FILE}" ]]; then
     echo "SUCCESS: Snapshot créé ${BACKUP_FILE}"
   
     # Optionnel : copier vers stockage externe
     # aws s3 cp "${BACKUP_FILE}" s3://my-vault-backups/
   
     # Nettoyer les anciens backups
     find "${BACKUP_DIR}" -name "*.snap" -mtime +${RETENTION_DAYS} -delete
   else
     echo "ERROR: Snapshot vide ou manquant"
     exit 1
   fi

4. Planifier avec cron :

   # Toutes les 6 heures
   0 */6 * * * /opt/vault/scripts/backup.sh >> /var/log/vault-backup.log 2>&1

Restaurer depuis un snapshot

Opération de récupération lourde

La restauration d’un snapshot Raft est une opération de récupération, pas une opération de confort quotidien. Elle écrase tout le stockage. La procédure exacte dépend du scénario de reprise (perte d’un nœud, perte du cluster entier, corruption…).

Suivez la documentation officielle de restore pour votre cas spécifique.

Procédure générale (cluster complet) :

1. Arrêter tous les nœuds

2. Sur un nœud, effectuer une restauration forcée :

   vault operator raft snapshot restore -force \
     /opt/vault/backups/vault-snapshot-XXXXXX.snap

   Le flag -force est souvent nécessaire pour les scénarios de disaster recovery.

3. Démarrer ce nœud et vérifier :

   sudo systemctl start vault
   vault status
   vault secrets list

4. Redémarrer les autres nœuds qui rejoindront le cluster

5. Vérifier le cluster :

   vault operator raft list-peers

Snapshot ≠ PRA complet

Un snapshot aide à la récupération des données, mais un Plan de Reprise d’Activité (PRA) complet suppose aussi :

Élément	À prévoir
Mécanisme de seal	Le KMS/HSM doit être accessible
Clés Shamir	Si utilisées, elles doivent être disponibles
Certificats TLS	Sauvegardés séparément
Configuration	vault.hcl et scripts
Procédure testée	Test de restauration mensuel

Glissez pour voir

Testez mensuellement

Un backup non testé n’est pas un backup. Planifiez un test de restauration mensuel sur un environnement isolé.

Opérations de maintenance

Rotation de la clé de chiffrement interne

Vault chiffre les données avec une clé interne qui peut être rotée sans downtime :

# Vérifier la clé actuelle
vault operator key-status

# Effectuer la rotation
vault operator rotate

# Vérifier la nouvelle version
vault operator key-status

Ce que cette rotation fait (et ne fait pas)

Cette rotation concerne la clé de protection interne du stockage Vault. Elle ne remplace pas :

• La rotation de vos secrets métiers (passwords, API keys…)
• La gestion du mécanisme de seal (KMS, HSM)
• La rotation des credentials dynamiques (gérée par TTL)

Les données existantes restent lisibles. Les nouvelles écritures utilisent la nouvelle clé.

Rotation des credentials root

Le root token initial ne doit jamais être conservé. Après l’initialisation :

1. Créer des admins avec des policies appropriées

2. Révoquer le root token initial :

   vault token revoke s.XXXXX

3. Si besoin d’un nouveau root token (urgence) :

   # Initier la régénération
   vault operator generate-root -init
   
   # Chaque holder de recovery key (ou unseal key) fournit sa part
   vault operator generate-root \
     -nonce=<nonce> \
     <recovery_key_share>
   
   # Une fois le seuil atteint, décoder le token
   vault operator generate-root \
     -decode=<encoded_token> \
     -otp=<otp>

Mise à jour de Vault

Avant toute mise à jour

• Vérifiez la compatibilité de version dans les release notes
• Testez d’abord sur un environnement non-production
• Planifiez une fenêtre de maintenance
• Ayez un snapshot récent

Package manager

# Mettre à jour le package
sudo apt update && sudo apt install vault

# Redémarrer (un nœud à la fois en HA)
sudo systemctl restart vault

# Vérifier la version
vault version

Binary

# Télécharger la nouvelle version
wget https://releases.hashicorp.com/vault/${VERSION}/vault_${VERSION}_linux_amd64.zip

# Vérifier le checksum
sha256sum -c vault_${VERSION}_SHA256SUMS

# Arrêter Vault
sudo systemctl stop vault

# Remplacer le binaire
unzip vault_${VERSION}_linux_amd64.zip
sudo mv vault /usr/local/bin/

# Redémarrer
sudo systemctl start vault

Procédure rolling update (cluster HA) :

1. Mettre à jour un standby (pas le leader)

2. Vérifier qu’il rejoint le cluster et fonctionne correctement

3. Répéter pour les autres standby

4. Step down le leader :

   vault operator step-down

5. Mettre à jour l’ancien leader devenu standby

6. Vérifier le cluster :

   vault operator raft list-peers
   vault version

Retirer un nœud du cluster

# Identifier le node_id à retirer
vault operator raft list-peers

# Retirer le nœud (depuis le leader)
vault operator raft remove-peer vault-old

Troubleshooting

Vault ne démarre pas

Vérifier les logs :

sudo journalctl -u vault -f

Causes fréquentes :

Erreur	Cause	Solution
permission denied	Mauvaises permissions	chown -R vault:vault /opt/vault
address already in use	Port 8200/8201 occupé	ss -tlnp | grep 8200
TLS handshake error	Certificat invalide	Vérifier dates, CA, SAN
KMS access denied	IAM insuffisant	Vérifier la policy KMS
seal configuration missing	Config seal absente	Vérifier vault.hcl

Glissez pour voir

Vault est scellé de manière inattendue

# Vérifier le statut
vault status

# Si auto-unseal, vérifier l'accès KMS
# AWS
aws kms describe-key --key-id alias/vault-unseal

# Si Shamir, désceller manuellement
vault operator unseal

Causes de scellement :

• Redémarrage du serveur
• Crash de Vault
• Appel explicite vault operator seal

Perte du mécanisme de seal

Si Vault redémarre alors que le mécanisme d’auto-unseal est indisponible (KMS/HSM inaccessible), il restera sealed. La perte durable du mécanisme de seal ou de sa clé peut rendre le cluster irrécupérable.

Assurez-vous que votre mécanisme de seal est lui-même hautement disponible.

Problèmes de cluster Raft

Vérifier l’état du cluster :

vault operator raft list-peers

Un nœud ne rejoint pas :

# Vérifier la connectivité réseau (port 8201)
nc -zv vault-1.internal 8201

# Vérifier les logs du nœud
sudo journalctl -u vault -f

# Forcer une nouvelle tentative
sudo systemctl restart vault

Split-brain (rare) :

Si le cluster se partitionne, les nœuds minoritaires deviennent standby sans leader. Une fois la connectivité rétablie, ils rejoignent automatiquement.

Performances dégradées

Diagnostiquer :

# Latence des opérations
vault read sys/health

# Métriques instantanées
curl -s https://vault:8200/v1/sys/metrics?format=prometheus | grep vault_

Causes fréquentes :

Symptôme	Cause probable	Solution
Latence lecture élevée	Disque lent	SSD/NVMe, vérifier IOPS
Latence écriture élevée	Réplication Raft	Réduire latence réseau
OOM / crash	RAM insuffisante	Augmenter RAM, réduire cache
Timeouts KMS	KMS distant/lent	Région KMS plus proche

Glissez pour voir

Audit logs ne s’écrivent plus

# Vérifier les audit devices
vault audit list

# Regarder l'espace disque
df -h /var/log

# Vérifier les permissions
ls -la /var/log/vault/

Audit bloquant

Par défaut, si tous les audit devices échouent, Vault refuse toutes les requêtes. C’est un choix de sécurité : mieux vaut un downtime qu’un trou dans les logs.

Checklist de sécurité production

Configuration minimale

• TLS activé sur tous les listeners
• Auto-unseal recommandé pour éviter l’intervention manuelle
• Audit device activé et fonctionnel
• Root token révoqué après initialisation
• mlock activé (sauf contrainte conteneur)

Shamir peut être justifié

Auto-unseal est recommandé pour la plupart des productions, mais Shamir peut être retenu dans certains contextes spécifiques (exigences de conformité, air-gap…). L’important est de comprendre les implications opérationnelles.

Réseau

• Firewall : ports 8200 (API) et 8201 (cluster) restreints
• Load balancer avec health checks /sys/health?standbyok=true
• Pas d’exposition directe à Internet

Policies et authentification

• Policies least privilege pour chaque rôle
• Pas de policy root pour les utilisateurs normaux
• Auth methods adaptées (OIDC, LDAP, Kubernetes)
• Token TTL courts (1h-8h max pour les interactifs)

Opérations

• Sauvegardes automatisées (minimum quotidien)
• Test de restauration mensuel sur environnement isolé
• Monitoring avec alertes sur sealed, no-leader, audit-failure
• Rotation clé chiffrement annuelle minimum

Secrets

• Secrets dynamiques privilégiés sur statiques
• TTL courts sur les leases
• Rotation automatique des credentials DB
• Response wrapping pour la distribution

À retenir

1. Cluster 3 nœuds minimum : la base pour une production résiliente
2. Auto-unseal recommandé : évite l’intervention manuelle au redémarrage
3. Monitoring : sealed, no-leader, audit-failure = alertes critiques
4. Backups testés : snapshot Raft quotidien + test mensuel
5. Rolling updates : un nœud à la fois, standby d’abord, vérifier les release notes
6. Audit obligatoire : sans audit, vous perdez la traçabilité
7. Dimensionnement = test de charge : les tableaux ne remplacent pas l’observation de votre charge réelle

Prochaines étapes

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

Policies ACL Écrire des policies de moindre privilège

Authentification Configurer les méthodes d'auth

Page pivot Vault Retour à la vue d'ensemble

×

📖 Voir la documentation →