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.

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

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

Dimensionnement du cluster

Deux décisions sont à prendre avant toute installation, et l'une est bien plus difficile à corriger que l'autre. Ajouter du CPU ou de la RAM à un nœud reste une opération banale ; changer le nombre de nœuds d'un cluster Raft touche au quorum et se planifie. Commencez donc par arrêter la topologie, puis dimensionnez les machines.

Combien de nœuds ?

La colonne « tolérance pannes » indique combien de nœuds peuvent disparaître sans que le cluster cesse de fonctionner. Au-delà de ce seuil, Vault ne perd pas ses données mais devient indisponible en écriture, faute de quorum.

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

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+

Facteurs de dimensionnement

Le nombre de requêtes par seconde ne suffit pas à prédire la charge, car toutes les opérations ne coûtent pas la même chose. Les facteurs ci-dessous expliquent pourquoi deux clusters au trafic identique peuvent avoir des besoins très différents ; identifiez ceux qui correspondent à votre usage avant de retenir une ligne du tableau précédent.

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

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é

Le stockage Raft intégré est aujourd'hui le mode recommandé : chaque nœud conserve une copie complète des données et le protocole d'élection désigne un leader, seul habilité à écrire. Cette architecture supprime la dépendance à un backend de stockage externe, mais impose deux contraintes que la suite détaille, un réseau à faible latence entre les nœuds et un répartiteur de charge capable de distinguer le leader des suiveurs.

Cluster Raft 3 nœuds

Le schéma situe les deux flux réseau à ne pas confondre : le port 8200 porte le trafic des clients, le port 8201 la réplication entre nœuds. Ils se filtrent séparément.

Architecture cluster Vault HA avec Raft

Configuration Raft multi-nœuds

Tous les nœuds partagent le même fichier de configuration à trois valeurs près, signalées juste après le bloc. Le paramètre retry_join mérite une attention particulière : il liste les autres nœuds à contacter au démarrage, et Vault réessaie tant qu'aucun ne répond, ce qui rend l'ordre de démarrage du cluster indifférent.

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

L'adhésion d'un nouveau nœud ne demande aucune commande de join explicite si retry_join est renseigné : le démarrage du service suffit. La vérification finale est la seule étape réellement importante, car un nœud peut démarrer sans pour autant devenir votant dans le cluster.

Préparer le nouveau nœud avec la même configuration (en adaptant node_id, cluster_addr, api_addr)
Démarrer Vault sur le nouveau nœud :
Fenêtre de terminal
```
sudo systemctl start vault
```
Le nœud contacte les leaders potentiels via retry_join

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

Load balancer et health checks

Le load balancer doit distribuer le trafic et vérifier la santé des nœuds. La subtilité propre à Vault tient au fait qu'un nœud en bonne santé peut répondre autre chose que 200 : le point d'entrée /v1/sys/health encode l'état du nœud dans le code HTTP lui-même. Un répartiteur configuré avec les réglages par défaut sortira donc du pool tous les nœuds suiveurs, alors qu'ils fonctionnent parfaitement.

Codes retour de /v1/sys/health

Ce tableau est la référence à garder sous la main au moment de configurer la sonde. Retenez que 503 et 501 signalent de vrais problèmes, un nœud scellé ou jamais initialisé, alors que 429 et 473 décrivent un fonctionnement normal en mode suiveur.

É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

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

Trois évènements justifient de réveiller quelqu'un la nuit sur un cluster Vault : le cluster est scellé, il n'a plus de leader, ou l'écriture des logs d'audit échoue. Dans les trois cas, les applications qui dépendent de Vault sont ou seront bloquées. Le reste de la métrologie sert au capacity planning et peut attendre les heures ouvrées.

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"]
}

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

Alertes Prometheus recommandées

Ces cinq règles couvrent les évènements décrits plus haut, avec des durées for: volontairement différentes. Un scellement se signale au bout d'une minute, alors qu'une perte de nœud attend cinq minutes : un redémarrage ordinaire ne doit pas déclencher d'astreinte. Adaptez le seuil mémoire de la dernière règle à la RAM réellement allouée à vos nœuds.

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

Un snapshot Vault contient les données chiffrées : il est inexploitable sans le mécanisme de scellement qui détient la clé. Cette propriété est rassurante côté confidentialité et redoutable côté reprise, puisque sauvegarder Vault sans sauvegarder l'accès à son KMS ou à ses clés Shamir revient à ne rien sauvegarder du tout. Les sections suivantes traitent les deux volets, la production des snapshots puis ce qu'il faut leur adjoindre pour qu'une restauration aboutisse.

Types de sauvegardes

L'édition de Vault détermine ce dont vous disposez : la planification native des snapshots est une fonction Enterprise, la Community Edition demande de l'outiller vous-même. La ligne « export secrets » n'est pas une sauvegarde du cluster, seulement une extraction ponctuelle de données.

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

Automatiser les snapshots Raft (CE)

L'automatisation repose sur un token dédié portant une policy réduite à la seule lecture du point d'entrée de snapshot. N'utilisez jamais un token d'administration pour cette tâche : il finirait stocké en clair sur la machine qui exécute la tâche planifiée.

Créer une policy de backup :

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

Créer un token dédié :

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

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

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

La restauration remplace l'intégralité du contenu du cluster par celui du snapshot : tout ce qui a été écrit depuis la prise de la sauvegarde est perdu, sans confirmation ni possibilité de retour. C'est une manœuvre de crise, à répéter au préalable sur un environnement isolé.

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

Arrêter tous les nœuds
Sur un nœud, effectuer une restauration forcée :
Fenêtre de terminal
```
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.

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

sudo systemctl start vault
vault status
vault secrets list

Redémarrer les autres nœuds qui rejoindront le cluster
Vérifier le cluster :
Fenêtre de terminal
```
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

Opérations de maintenance

Les quatre opérations qui suivent reviennent régulièrement dans la vie d'un cluster. Deux se font sans interruption de service, la rotation de la clé interne et le retrait d'un nœud ; les deux autres, régénération d'un token root et montée de version, demandent une préparation et un snapshot récent. Aucune ne doit être découverte le jour où elle devient urgente.

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

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 :

Créer des admins avec des policies appropriées
Révoquer le root token initial :
Fenêtre de terminal
```
vault token revoke s.XXXXX
```

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

Vault ne prend pas en charge le retour à une version antérieure : le format de stockage évolue et un binaire plus ancien peut refuser de lire les données migrées. Le snapshot pris avant la mise à jour est donc votre seule voie de repli.

Package manager
Binary

# 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

# Télécharger l'archive ET le fichier de sommes officiel
wget https://releases.hashicorp.com/vault/${VERSION}/vault_${VERSION}_linux_amd64.zip
wget https://releases.hashicorp.com/vault/${VERSION}/vault_${VERSION}_SHA256SUMS

# Vérifier l'empreinte de l'archive téléchargée (doit afficher "OK")
sha256sum --ignore-missing -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) :

Mettre à jour un standby (pas le leader)
Vérifier qu'il rejoint le cluster et fonctionne correctement
Répéter pour les autres standby
Step down le leader :
Fenêtre de terminal
```
vault operator step-down
```
Mettre à jour l'ancien leader devenu standby

Vérifier le cluster :

vault operator raft list-peers
vault version

Retirer un nœud du cluster

Le retrait doit être demandé au leader et se fait par node_id, pas par adresse. Retirer un nœud diminue le quorum : passer de 3 à 2 nœuds fait tomber la tolérance aux pannes à zéro, prévoyez le remplaçant avant l'opération.

# 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

Les pannes rencontrées sur Vault se rangent dans quatre familles, traitées dans l'ordre de fréquence : le service ne démarre pas, le cluster est scellé, les nœuds ne s'accordent plus, ou les temps de réponse se dégradent. Un réflexe vaut pour toutes : vault status d'abord, il indique en une commande si le nœud est initialisé, scellé, et qui est le leader.

Vault ne démarre pas

À ce stade Vault n'a pas encore ouvert son API, le diagnostic passe donc uniquement par les journaux du service. Les causes sont presque toujours des problèmes d'environnement, permissions de fichiers, port déjà pris ou certificat invalide, pas des problèmes de configuration Vault elle-même.

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`

Vault est scellé de manière inattendue

Un nœud scellé répond encore sur son API mais refuse toute opération sur les secrets : la clé de déchiffrement n'est plus en mémoire. La marche à suivre dépend entièrement du mécanisme configuré, automatique via un KMS ou manuel via les parts de clé Shamir.

# 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

Problèmes de cluster Raft

Ces incidents se manifestent par un nœud absent de la liste des pairs, ou par des changements de leader à répétition. La cause est presque toujours réseau et concerne le port 8201, distinct de celui de l'API : un pare-feu qui autorise 8200 mais bloque 8201 laisse des nœuds joignables par les clients tout en les empêchant de former un cluster.

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

Avant de conclure à un sous-dimensionnement, séparez les lectures des écritures. Une lecture lente pointe vers le disque local du nœud interrogé ; une écriture lente met en cause la réplication Raft, donc la latence réseau entre les nœuds, puisque toute écriture doit être confirmée par une majorité d'entre eux.

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

Audit logs ne s'écrivent plus

Cette panne est prioritaire sur toutes les autres, car elle rend Vault inutilisable, comme l'explique l'encadré qui suit. Les trois causes à écarter en premier sont un disque plein, des permissions incorrectes sur le répertoire de destination, et une rotation de journaux qui a déplacé le fichier attendu.

# 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/

Checklist de sécurité production

Cette checklist sert de revue avant mise en service, puis de contrôle périodique. Elle est ordonnée du plus contraignant au plus fin : un manquement dans la première section rend le cluster vulnérable dès le premier jour, alors que les sections suivantes traitent de durcissement progressif.

Configuration minimale

Ces cinq points constituent le seuil en dessous duquel un cluster ne devrait pas recevoir de trafic de production. Le plus souvent oublié est la révocation du token root initial, qui reste sinon un accès total et permanent, hors de tout contrôle de policy.

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)

Réseau

Vault n'a pas vocation à être joignable depuis Internet : ses clients sont vos applications et vos administrateurs. Les deux ports se filtrent séparément, 8200 pour les clients, 8201 uniquement entre les nœuds du cluster.

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

Une policy Vault n'autorise que ce qu'elle nomme explicitement, tout le reste est refusé. Ce point est à votre avantage : partez d'une policy vide et ajoutez les chemins un par un, plutôt que de retirer des droits à une policy trop large.

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

Ces quatre points relèvent de la routine et se vérifient dans le temps, pas au moment de la mise en service. Le test de restauration est celui qui se néglige le plus vite alors qu'il est le seul à prouver que les sauvegardes fonctionnent.

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

Le dernier niveau porte sur l'usage que les applications font de Vault. Un cluster parfaitement durci qui ne distribue que des secrets statiques à durée de vie illimitée n'apporte guère plus qu'un fichier de configuration protégé.

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

À retenir

Cluster 3 nœuds minimum : la base pour une production résiliente
Auto-unseal recommandé : évite l'intervention manuelle au redémarrage
Monitoring : sealed, no-leader, audit-failure = alertes critiques
Backups testés : snapshot Raft quotidien + test mensuel
Rolling updates : un nœud à la fois, standby d'abord, vérifier les release notes
Audit obligatoire : sans audit, vous perdez la traçabilité
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