Skip to content
Learni
Voir tous les tutoriels
DevOps

Comment configurer HashiCorp Vault en mode serveur 2026

Read in English

Introduction

HashiCorp Vault est l'outil de référence pour la gestion centralisée des secrets en 2026. Il permet de stocker, chiffrer et contrôler l'accès à des credentials comme des API keys, certificats ou mots de passe de base de données. Contrairement à des fichiers .env dispersés, Vault offre un audit complet, une rotation automatique et une haute disponibilité.

Ce tutoriel intermediate vous guide pas à pas pour installer Vault en mode serveur (pas dev), avec un stockage fichier persistant, un listener TCP sécurisé, des politiques HCL, l'engine KV v2 et l'authentification userpass. À la fin, vous manipulerez des secrets via CLI et API. Parfait pour des environnements DevOps ou pré-prod. Le setup est fonctionnel sur Linux/Mac, scalable vers Kubernetes. Temps estimé : 20 minutes. Pourquoi c'est crucial ? 70% des breaches viennent de secrets mal gérés (rapport Verizon DBIR 2025).

Prérequis

  • Système Linux ou macOS (Vault non supporté natif Windows sans WSL)
  • Utilisateur avec droits sudo pour /opt/vault
  • 2 Go RAM libre
  • Connaissances de base en CLI et chiffrement (AES-256)
  • Optionnel : curl pour tests API

Télécharger et installer Vault

install-vault.sh
#!/bin/bash

# Télécharger la dernière version stable (1.17.x en 2026)
VAULT_VERSION=1.17.0
wget https://releases.hashicorp.com/vault/${VAULT_VERSION}/vault_${VAULT_VERSION}_linux_amd64.zip

# Décompresser et installer
unzip vault_${VAULT_VERSION}_linux_amd64.zip
sudo mv vault /usr/local/bin/
sudo chmod +x /usr/local/bin/vault

# Vérifier l'installation
vault --version

# Créer répertoires de données
sudo mkdir -p /opt/vault/data /opt/vault/logs /opt/vault/config
sudo chown -R $(whoami):$(whoami) /opt/vault

Ce script télécharge Vault depuis les releases officielles HashiCorp, l'installe dans PATH système et prépare les dossiers pour stockage, logs et config. Utilisez chmod +x install-vault.sh && ./install-vault.sh. Évitez les versions snapshot pour la prod ; vérifiez toujours la signature GPG pour l'intégrité.

Fichier de configuration HCL

/opt/vault/config/vault.hcl
storage "file" {
  path = "/opt/vault/data"
}

listener "tcp" {
  address     = "127.0.0.1:8200"
  tls_disable = false
  tls_cert_file = "/opt/vault/config/vault.crt"
  tls_key_file  = "/opt/vault/config/vault.key"
}

ui = true

log_level = "info"

# Auto-unseal avec Transit (optionnel, ici manuel pour simplicité)
# seal "transit" { ... }

disable_mlock = true

api_addr = "https://127.0.0.1:8200"
cluster_addr = "https://127.0.0.1:8201"

Cette config HCL définit un backend stockage fichier persistant, un listener TCP local avec TLS activé (générez certs après), l'UI web et les adresses API/cluster. Le disable_mlock évite les erreurs sur certains OS. Copiez ce fichier ; TLS est critique pour éviter les MITM.

Générer certificats TLS auto-signés

gen-certs.sh
#!/bin/bash

cd /opt/vault/config

# Générer clé privée et certificat auto-signé (pour tests locaux)
openssl req -newkey rsa:2048 -nodes -keyout vault.key -x509 -days 365 -out vault.crt -subj "/CN=vault.local"

# Permissions sécurisées
chmod 600 vault.key
chmod 644 vault.crt

# Vérifier
openssl x509 -in vault.crt -text -noout | grep -A1 "Subject:"

Générez des certs TLS basiques pour le listener (remplacez par Let's Encrypt en prod). Exécutez chmod +x gen-certs.sh && ./gen-certs.sh. Cela sécurise les communications API/CLI dès le démarrage, évitant les erreurs 'connection refused' sans HTTPS.

Démarrer le serveur Vault

start-vault.sh
#!/bin/bash

# Démarrer Vault en foreground (utilisez systemd en prod)
nohup vault server -config=/opt/vault/config/vault.hcl > /opt/vault/logs/vault.log 2>&1 &

# Attendre démarrage
sleep 5

# Vérifier status
curl -k https://127.0.0.1:8200/v1/sys/health | jq .

Ce script lance Vault avec la config HCL en arrière-plan, redirige les logs et teste la santé via API (ignore certs avec -k pour tests). Status '200' = sealed mais initialized false. En prod, utilisez un service systemd pour restart auto.

Initialiser et unseal Vault

init-unseal.sh
#!/bin/bash

export VAULT_ADDR='https://127.0.0.1:8200'

# Initialiser (une seule fois)
vault operator init > /opt/vault/init-keys.txt

# Récupérer les clés (exemple : remplacez par vos vraies)
UNSEAL_KEY1=$(grep 'Unseal Key 1:' /opt/vault/init-keys.txt | cut -d' ' -f4)
UNSEAL_KEY2=$(grep 'Unseal Key 2:' /opt/vault/init-keys.txt | cut -d' ' -f4)
UNSEAL_KEY3=$(grep 'Unseal Key 3:' /opt/vault/init-keys.txt | cut -d' ' -f4)

# Unseal (3/5 shamirs)
vault operator unseal $UNSEAL_KEY1
vault operator unseal $UNSEAL_KEY2
vault operator unseal $UNSEAL_KEY3

# Login root (gardez secret !)
ROOT_TOKEN=$(grep 'Initial Root Token:' /opt/vault/init-keys.txt | cut -d' ' -f4)
vault login $ROOT_TOKEN

# Status
vault status

Initialisez Vault pour générer root token et unseal keys (Shamir secret sharing). Remplacez les clés extraites par les vôtres du fichier init-keys.txt. Après 3 unseal, Vault est actif. Sauvegardez init-keys.txt hors ligne ; perdues = données perdues.

Activer KV v2 et créer une policy

/tmp/policy-kv.hcl
path "secret/data/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

path "secret/metadata/*" {
  capabilities = ["list"]
}

Cette policy HCL donne accès read/write sur l'engine KV v2 à 'secret/'. vault policy write kv-rw /tmp/policy-kv.hcl puis vault write auth/userpass/users/testuser password=testpass policies=kv-rw pour l'appliquer. Sépare data/metadata pour audits fins.

Stocker/retrouver secret via CLI et API

manage-secret.sh
#!/bin/bash

export VAULT_ADDR='https://127.0.0.1:8200'

# Activer KV v2
vault secrets enable -path=secret kv-v2

# Créer userpass auth
vault auth enable userpass
vault write auth/userpass/users/appuser password=AppPass123! policies=kv-rw

# Login et stocker secret
vault login -method=userpass username=appuser password=AppPass123!
vault kv put secret/myapp db_password=supersecret123 api_key=sk-abc123

# Récupérer
vault kv get secret/myapp

# Via API curl (avec token)
TOKEN=$(vault print token)
curl -s -k -H "X-Vault-Token: $TOKEN" -X GET https://127.0.0.1:8200/v1/secret/data/myapp | jq .data.data

Activez KV v2 pour versioning auto, configurez auth userpass, stockez un secret et récupérez-le via CLI/API. Le token est éphémère ; utilisez AppRole en prod. KV v2 stocke metadata séparément pour rotations sans downtime.

Bonnes pratiques

  • Toujours activer audit logs : vault audit enable file file_path=/opt/vault/audit.log pour traçabilité.
  • Utilisez auto-unseal avec AWS KMS ou Transit pour éviter unseal manuel au boot.
  • Policies least-privilege : granularisez par path/capability, évitez root token.
  • Haute disponibilité : passez à Consul/raft storage pour cluster.
  • Rotatez tokens et utilisez TTL : vault token create -ttl=1h.

Erreurs courantes à éviter

  • Oublier unseal : Vault reste sealed, API 5xx ; vérifiez vault status.
  • TLS mal configuré : Erreurs 'certificate signed by unknown' ; utilisez -k pour tests ou CA trusted.
  • VAULT_ADDR sans https : CLI refuse connexion sécurisée en 2026.
  • Perte init keys : Pas de recovery ; backup chiffré hors ligne obligatoire.

Pour aller plus loin

Maîtrisez Vault en prod avec nos formations Learni DevOps. Ressources : Docs Vault officielles, Tutoriel Kubernetes Vault Injector, communauté HCL avancées sur GitHub.