Skip to content
Learni
Voir tous les tutoriels
DevOps & Infrastructure

Comment maîtriser HashiCorp Vault en production 2026

18 minADVANCED
SécuritéKubernetesHashiCorp Vault
Read in English

Introduction

HashiCorp Vault est la référence pour la gestion centralisée des secrets en entreprise. En 2026, les exigences de conformité et de rotation automatique imposent une architecture robuste avec stockage distribué et politiques dynamiques. Ce tutoriel vous guide pas à pas vers un déploiement production-grade avec Raft, TLS mutuel et intégration Kubernetes. Vous apprendrez à éviter les fuites de secrets tout en automatisant leur cycle de vie.

Prérequis

  • Kubernetes 1.28+ avec Helm 3.12+
  • HashiCorp Vault 1.17+
  • Connaissances avancées de RBAC et TLS
  • Cluster avec au moins 3 nœuds pour le quorum Raft
  • Cert-manager installé pour les certificats

Déploiement avec Helm et Raft

vault-values.yaml
global:
  enabled: true
server:
  standalone:
    enabled: false
  ha:
    enabled: true
    raft:
      enabled: true
      setNodeId: true
  dataStorage:
    enabled: true
    size: 10Gi
  extraEnvironmentVars:
    VAULT_LOG_LEVEL: "info"
ui:
  enabled: true
  serviceType: "ClusterIP"

Ce fichier values active le mode HA avec stockage Raft pour la haute disponibilité. Le quorum nécessite au moins 3 pods pour tolérer une panne.

Installation du chart Helm

terminal
helm repo add hashicorp https://helm.releases.hashicorp.com
helm install vault hashicorp/vault -n vault --create-namespace -f vault-values.yaml
kubectl wait --for=condition=ready pod -l app.kubernetes.io/name=vault -n vault --timeout=300s

La commande déploie Vault en mode HA. Attendez que les pods soient prêts avant d'initialiser le cluster.

Initialisation et déverrouillage

init-vault.sh
#!/bin/bash
kubectl exec -n vault vault-0 -- vault operator init -key-shares=5 -key-threshold=3 > vault-init.txt
kubectl create secret generic vault-keys -n vault --from-file=vault-init.txt

L'initialisation génère 5 clés unseal dont 3 sont nécessaires. Stockez-les immédiatement dans un secret Kubernetes chiffré.

Configuration des politiques avancées

app-policy.hcl
path "secret/data/app/*" {
  capabilities = ["create", "read", "update", "delete"]
}
path "database/creds/app-role" {
  capabilities = ["read"]
  allowed_parameters = {
    "ttl" = ["1h", "2h"]
  }
}

Cette politique HCL limite les accès aux secrets d'application et aux credentials dynamiques de base de données avec TTL contrôlé.

Activation des secrets engines dynamiques

enable-engines.sh
vault secrets enable -path=secret kv-v2
vault secrets enable database
vault write database/config/postgres \
  plugin_name=postgresql-database-plugin \
  allowed_roles="app-role" \
  connection_url="postgresql://{{username}}:{{password}}@postgres:5432/app"

Active KV v2 et le moteur database pour générer des identifiants temporaires avec rotation automatique.

Bonnes pratiques

  • Toujours utiliser des politiques avec TTL stricts et least privilege
  • Stocker les clés unseal dans un HSM ou un gestionnaire externe
  • Activer l'audit logging vers un SIEM
  • Implémenter le chiffrement TLS mutuel entre agents et Vault
  • Tester régulièrement la restauration des snapshots Raft

Erreurs courantes à éviter

  • Oublier de chiffrer les clés unseal (risque de fuite totale)
  • Utiliser un seul nœud en production (perte de quorum)
  • Négliger la rotation des tokens d'authentification
  • Configurer des chemins de secrets trop permissifs sans audit

Pour aller plus loin

Découvrez nos formations avancées sur la sécurisation des infrastructures : https://learni-group.com/formations. Approfondissez l'intégration de Vault avec SPIRE et les workloads serverless.