Installer et configurer HashiCorp Vault

Ce guide vous accompagne de l’installation de Vault jusqu’à un premier serveur persistant. Vous commencerez par le mode dev (pour apprendre), puis vous configurerez un serveur avec stockage Raft, initialisation et audit.

Ce guide n'est pas un guide de production HA

Ce guide couvre l’installation et un premier déploiement mono-nœud. C’est suffisant pour un lab avancé, une maquette ou une petite infrastructure tolérante à la panne.

Pour un déploiement production réel, vous devrez ajouter : haute disponibilité (3+ nœuds), auto-unseal, sauvegardes, monitoring, load balancing, et certificats signés par une vraie CA.

Consultez la section Ce guide ne couvre pas en fin de page.

Ce que vous allez apprendre

• Installer Vault via package officiel (recommandé) ou binaire manuel
• Démarrer un serveur mode dev pour les tests
• Configurer un premier serveur persistant avec Raft
• Comprendre Shamir vs auto-unseal
• Initialiser et déverrouiller Vault
• Activer l’audit pour la traçabilité

Prérequis

Concepts Vault Architecture, secrets engines et méthodes d'authentification

• Linux (Debian/Ubuntu, RHEL/Fedora, ou autre)
• Accès root ou sudo
• curl et gpg installés

Installation de Vault

Vault peut être installé de deux manières. Choisissez une seule méthode :

Méthode	Avantages	Inconvénients
Package officiel	Service systemd inclus, mises à jour simplifiées, utilisateur créé	Dépendance au repo HashiCorp
Binaire manuel	Contrôle total, pas de dépendance externe	Configuration manuelle du service

Glissez pour voir

Package officiel (recommandé)

Le package officiel HashiCorp installe :

• Le binaire /usr/bin/vault
• Un utilisateur système vault
• Une unité systemd /usr/lib/systemd/system/vault.service
• Une configuration de base /etc/vault.d/vault.hcl

Debian / Ubuntu

1. Ajouter la clé GPG HashiCorp

   sudo apt update && sudo apt install -y gpg
   
   wget -O- https://apt.releases.hashicorp.com/gpg | \
     sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg

2. Ajouter le dépôt

   echo "deb [arch=$(dpkg --print-architecture) \
     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

3. Installer Vault

   sudo apt update && sudo apt install -y vault

4. Vérifier l’installation

   vault version
   # Vault v1.21.4 (...)
   
   # Vérifier que le service existe
   systemctl status vault
   # ● vault.service - "HashiCorp Vault..."

RHEL / Fedora / CentOS

# Ajouter le dépôt HashiCorp
sudo dnf config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo

# Installer Vault
sudo dnf install -y vault

# Vérifier
vault version

Binaire manuel

L’installation manuelle vous donne un contrôle total, mais vous devez créer l’utilisateur, les répertoires et le service systemd vous-même.

Télécharger et vérifier le binaire

Toujours vérifier les binaires

Vault gère vos secrets les plus sensibles. Ne faites jamais confiance à un binaire téléchargé sans vérifier son intégrité. HashiCorp fournit des checksums signés avec leur clé PGP.

1. Télécharger le binaire et les fichiers de vérification

   VERSION="1.21.4"
   ARCH="amd64"  # ou arm64
   
   cd /tmp
   
   # Télécharger le binaire, les checksums et la signature
   curl -LO "https://releases.hashicorp.com/vault/${VERSION}/vault_${VERSION}_linux_${ARCH}.zip"
   curl -LO "https://releases.hashicorp.com/vault/${VERSION}/vault_${VERSION}_SHA256SUMS"
   curl -LO "https://releases.hashicorp.com/vault/${VERSION}/vault_${VERSION}_SHA256SUMS.sig"

2. Importer la clé PGP HashiCorp

   # Importer la clé publique HashiCorp
   curl -sL https://www.hashicorp.com/.well-known/pgp-key.txt | gpg --import
   
   # Vérifier l'empreinte (doit contenir : 34365D9472D7468F)
   gpg --list-keys --fingerprint security@hashicorp.com

3. Vérifier la signature des checksums

   gpg --verify vault_${VERSION}_SHA256SUMS.sig vault_${VERSION}_SHA256SUMS
   # Doit afficher : Good signature from "HashiCorp Security..."

4. Vérifier le checksum du binaire

   sha256sum -c vault_${VERSION}_SHA256SUMS --ignore-missing
   # Doit afficher : vault_1.21.4_linux_amd64.zip: OK

5. Extraire et installer

   unzip vault_${VERSION}_linux_${ARCH}.zip
   sudo mv vault /usr/local/bin/
   sudo chmod +x /usr/local/bin/vault
   
   vault version

Créer l’utilisateur et les répertoires

# Créer l'utilisateur système (sans login)
sudo useradd --system --home /opt/vault --shell /bin/false vault

# Créer les répertoires
sudo mkdir -p /opt/vault/{data,config,tls,logs}

# Définir les permissions
sudo chown -R vault:vault /opt/vault
sudo chmod 700 /opt/vault/data
sudo chmod 700 /opt/vault/logs

Créer le service systemd

Créez /etc/systemd/system/vault.service :

[Unit]
Description=HashiCorp Vault
Documentation=https://www.vaultproject.io/docs/
Requires=network-online.target
After=network-online.target

[Service]
User=vault
Group=vault
ExecStart=/usr/local/bin/vault server -config=/opt/vault/config/vault.hcl
ExecReload=/bin/kill --signal HUP $MAINPID
KillMode=process
KillSignal=SIGINT
Restart=on-failure
RestartSec=5
LimitNOFILE=65536
LimitMEMLOCK=infinity
# Permettre mlock sans privilèges root
CapabilityBoundingSet=CAP_IPC_LOCK
AmbientCapabilities=CAP_IPC_LOCK

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload

Mode dev : pour apprendre et tester

Le mode dev est conçu pour l’apprentissage et les tests locaux. Il démarre un serveur Vault complet en quelques secondes, sans configuration.

Ce que fait le mode dev

Caractéristique	Valeur
Stockage	Mémoire (perdu au redémarrage)
Protocole	HTTP (non chiffré)
État initial	Déjà initialisé et déverrouillé
Secrets engine	KV v2 activé sur secret/
Token root	Affiché au démarrage

Glissez pour voir

Jamais en dehors d'un lab local !

Le mode dev n’est pas sécurisé : HTTP en clair, stockage volatile, token root exposé. Il est uniquement destiné à l’apprentissage sur votre machine locale.

Démarrer le serveur dev

Dans un premier terminal :

vault server -dev -dev-root-token-id="root"

L’option -dev-root-token-id définit un token root prévisible pour simplifier les tests. Vous verrez :

==> Vault server configuration:

             Api Address: http://127.0.0.1:8200
...
Root Token: root
Development mode should NOT be used in production installations!

Configurer le client

Dans un second terminal :

export VAULT_ADDR='http://127.0.0.1:8200'
export VAULT_TOKEN='root'

vault status

Sortie attendue :

Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
...
Storage Type    inmem

Initialized: true et Sealed: false : vous pouvez utiliser Vault.

Premier test rapide

vault kv put secret/test message="Hello Vault!"
vault kv get secret/test

Si vous voyez votre secret, bravo ! Passons à un déploiement persistant.

Premier serveur persistant

Cette section configure un serveur Vault mono-nœud avec stockage Raft. C’est adapté pour :

• Un lab avancé ou une maquette
• Un environnement de développement partagé
• Une petite infrastructure tolérante à une indisponibilité temporaire

Ce n'est pas encore de la production

Un serveur mono-nœud avec certificat auto-signé et unseal manuel n’est pas un déploiement production. Consultez la section Ce guide ne couvre pas pour les étapes supplémentaires.

Architecture cible

Fichier de configuration

Installation package

Modifiez /etc/vault.d/vault.hcl :

# Interface utilisateur web
ui = true

# Stockage avec Raft (intégré)
storage "raft" {
  path    = "/opt/vault/data"
  node_id = "vault-1"
}

# Listener HTTPS
listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_cert_file = "/opt/vault/tls/vault.crt"
  tls_key_file  = "/opt/vault/tls/vault.key"
}

# Adresses pour l'API et le cluster
api_addr     = "https://vault.example.com:8200"
cluster_addr = "https://vault.example.com:8201"

# Log level
log_level = "info"

Créez les répertoires nécessaires :

sudo mkdir -p /opt/vault/{data,tls,logs}
sudo chown -R vault:vault /opt/vault
sudo chmod 700 /opt/vault/data

Installation binaire

Créez /opt/vault/config/vault.hcl :

# Interface utilisateur web
ui = true

# Stockage avec Raft (intégré)
storage "raft" {
  path    = "/opt/vault/data"
  node_id = "vault-1"
}

# Listener HTTPS
listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_cert_file = "/opt/vault/tls/vault.crt"
  tls_key_file  = "/opt/vault/tls/vault.key"
}

# Adresses pour l'API et le cluster
api_addr     = "https://vault.example.com:8200"
cluster_addr = "https://vault.example.com:8201"

# Log level
log_level = "info"

À propos de mlock

Par défaut, Vault utilise mlock pour empêcher les secrets d’être écrits sur le swap. C’est une protection importante en production.

Environnement	Recommandation
Lab / dev	disable_mlock = true acceptable pour simplifier
Production	Garder mlock actif + désactiver le swap + capabilities systemd

Glissez pour voir

Si vous avez l’erreur mlock: operation not permitted :

Option 1 (recommandée) : Ajouter les capabilities dans systemd (déjà fait dans notre unité avec AmbientCapabilities=CAP_IPC_LOCK)

Option 2 (lab uniquement) : Ajouter disable_mlock = true dans la config

mlock en production

La documentation de hardening HashiCorp recommande de garder mlock actif, de désactiver le swap sur le serveur, et d’accorder la capability IPC_LOCK via systemd ou setcap. disable_mlock = true est un compromis acceptable en lab, mais pas en production.

Certificats TLS

Vault doit utiliser HTTPS, même pour un lab. Pour un premier test, vous pouvez créer un certificat auto-signé :

# Certificat auto-signé (lab uniquement)
sudo openssl req -x509 -nodes -days 365 \
  -newkey rsa:2048 \
  -keyout /opt/vault/tls/vault.key \
  -out /opt/vault/tls/vault.crt \
  -subj "/CN=vault.example.com"

sudo chown vault:vault /opt/vault/tls/*
sudo chmod 600 /opt/vault/tls/vault.key

Certificat auto-signé = lab uniquement

En production, utilisez des certificats signés par une vraie CA (interne ou publique). Une fois Vault opérationnel, vous pouvez utiliser son engine PKI pour générer vos certificats : guide PKI.

Démarrer le serveur

sudo systemctl enable vault
sudo systemctl start vault
sudo systemctl status vault

Vérifier le statut

export VAULT_ADDR='https://vault.example.com:8200'

# Si certificat auto-signé (lab uniquement !)
export VAULT_CACERT=/opt/vault/tls/vault.crt
# OU (moins sécurisé)
export VAULT_SKIP_VERIFY=1

vault status

VAULT_SKIP_VERIFY = lab uniquement

VAULT_SKIP_VERIFY=1 désactive la vérification TLS. C’est dangereux et ne doit être utilisé qu’en lab avec un certificat auto-signé. En production, installez votre CA dans le trust store du système ou utilisez VAULT_CACERT.

Sortie attendue (serveur non initialisé) :

Key                Value
---                -----
Seal Type          shamir
Initialized        false
Sealed             true
...

Shamir vs Auto-unseal

Avant d’initialiser Vault, comprenez les deux mécanismes de déverrouillage.

Shamir (par défaut)

Vault utilise l’algorithme de Shamir’s Secret Sharing pour diviser la clé maître en plusieurs parts (shares). Vous définissez :

• key-shares : nombre total de parts (ex: 5)
• key-threshold : nombre minimum pour déverrouiller (ex: 3)

Avantages :

• Aucune dépendance externe
• Gouvernance multi-personnes (plusieurs détenteurs de clés)
• Bon pour comprendre le mécanisme

Inconvénients :

• Intervention humaine à chaque redémarrage
• Complique l’automatisation (CI/CD, auto-scaling)
• Risque d’indisponibilité si les détenteurs sont absents

Auto-unseal (recommandé en exploitation)

Vault délègue le déchiffrement à un service externe de confiance :

Méthode	Fournisseur	Prérequis
AWS KMS	Amazon Web Services	Clé KMS + IAM role
Azure Key Vault	Microsoft Azure	Key Vault + managed identity
GCP Cloud KMS	Google Cloud	Clé KMS + service account
Transit	Un autre Vault	Cluster Vault dédié
HSM	PKCS#11	Hardware Security Module

Glissez pour voir

Avantages :

• Déverrouillage automatique au redémarrage
• Compatible avec l’automatisation (Kubernetes, auto-scaling)
• Meilleure expérience opérationnelle

Inconvénients :

• Dépendance à un service externe
• Coût du service KMS/HSM
• Configuration initiale plus complexe

Recommandation HashiCorp

La documentation officielle indique que pour la plupart des utilisateurs, auto-unseal offre une meilleure expérience que l’unseal manuel via Shamir. Shamir reste utile pour comprendre le mécanisme ou dans des environnements air-gapped sans accès cloud.

Ce guide utilise Shamir

Pour ce premier déploiement, nous utilisons Shamir car il ne nécessite aucune infrastructure externe. Une fois familiarisé avec Vault, configurez auto-unseal pour vos environnements d’exploitation.

Initialisation de Vault

L’initialisation est une opération unique qui génère la clé maître et les clés de déverrouillage.

Pour un lab (1 clé)

vault operator init -key-shares=1 -key-threshold=1

1 clé = pas de gouvernance

-key-shares=1 -key-threshold=1 signifie qu’une seule personne contrôle tout. C’est acceptable pour un lab personnel, mais jamais pour un environnement partagé ou de production.

Pour un environnement partagé (3 sur 5)

vault operator init -key-shares=5 -key-threshold=3

Sortie :

Unseal Key 1: lWF1ue8BgtW3/19Uf49GaAicvaebxtFWlDFvEIKvs3s=
Unseal Key 2: ...
Unseal Key 3: ...
Unseal Key 4: ...
Unseal Key 5: ...

Initial Root Token: hvs.FkLQnkIPosIar9SSeDfdsFEb

Vault initialized with 5 key shares and a key threshold of 3.

Sauvegardez ces informations !

Les unseal keys et le root token sont les éléments les plus sensibles.

• Stockez-les séparément : chaque clé chez une personne différente
• Utilisez un gestionnaire de mots de passe avec accès restreint
• Ne les commitez jamais dans un repo
• Sans eux : impossible de déverrouiller Vault après un redémarrage

Déverrouillage (Unseal)

Après chaque redémarrage, Vault démarre scellé (sealed). Il faut le déverrouiller avec les clés Shamir.

Pourquoi ce mécanisme ?

Quand Vault est scellé, les données sont chiffrées et inaccessibles. Même si un attaquant vole le serveur ou accède au stockage, il ne peut rien lire sans les clés de déverrouillage.

Procédure

Répétez la commande avec le nombre de clés requis (threshold) :

vault operator unseal <unseal_key_1>
vault operator unseal <unseal_key_2>
vault operator unseal <unseal_key_3>

Après chaque clé, Vault affiche la progression :

Unseal Progress    2/3

Une fois le seuil atteint :

Sealed          false     <-- Déverrouillé !

Authentification

vault login <root_token>

Activer l’audit

L’audit est essentiel pour la traçabilité. Il enregistre chaque opération sur Vault : qui a lu quel secret, quand, depuis quelle IP.

L'audit n'est pas activé par défaut

Contrairement à ce qu’on pourrait croire, Vault ne journalise rien par défaut. Vous devez activer explicitement un audit device.

Activer l’audit fichier

# Créer le répertoire (déjà fait si vous avez suivi le guide)
sudo mkdir -p /opt/vault/logs
sudo chown vault:vault /opt/vault/logs

# Activer l'audit device
vault audit enable file file_path=/opt/vault/logs/vault-audit.log

Vérifiez que l’audit fonctionne :

vault audit list

Path     Type    Description
----     ----    -----------
file/    file    n/a

Tester l’audit

Créez un secret et vérifiez que l’opération est journalisée :

vault kv put secret/test foo=bar

# Vérifier le log
sudo tail -1 /opt/vault/logs/vault-audit.log | jq .

Vous verrez une entrée JSON avec l’opération, l’utilisateur, la date, etc.

Rotation des logs

Ajoutez une rotation dans /etc/logrotate.d/vault :

/opt/vault/logs/*.log {
    daily
    rotate 30
    compress
    delaycompress
    notifempty
    missingok
    postrotate
        /bin/kill -HUP $(cat /run/vault.pid 2>/dev/null) 2>/dev/null || true
    endscript
}

Vérification des permissions

Pour un déploiement plus strict, Vault peut vérifier les permissions des fichiers de configuration au démarrage :

# Dans le fichier d'environnement du service
# ou avant de démarrer Vault
export VAULT_ENABLE_FILE_PERMISSIONS_CHECK=true

Cela génère des warnings si les fichiers de configuration sont lisibles par d’autres utilisateurs.

Dépannage

Symptôme	Cause probable	Solution
connection refused	Vault n’est pas démarré	systemctl start vault
Vault is sealed	Vault n’est pas déverrouillé	vault operator unseal
permission denied	Token invalide ou expiré	vault login avec le bon token
certificate signed by unknown authority	Certificat auto-signé non reconnu	export VAULT_CACERT=/path/to/ca.crt
mlock: operation not permitted	Capabilities manquantes	Vérifier AmbientCapabilities dans systemd
Listener config not found	Erreur de syntaxe HCL	vault server -config=... -dev pour tester

Glissez pour voir

Ce guide ne couvre pas

Ce guide vous donne une base fonctionnelle, mais un déploiement production réel nécessite des étapes supplémentaires :

Sujet	Pourquoi c’est important
Haute disponibilité (3+ nœuds)	Tolérance aux pannes, pas d’interruption de service
Auto-unseal (KMS/HSM)	Redémarrage automatique sans intervention humaine
Sauvegardes / snapshots Raft	Récupération après incident
Monitoring / telemetry	Détecter les problèmes avant qu’ils ne deviennent critiques
Load balancing	Répartition de charge et point d’entrée unique
Certificats signés par une vraie CA	TLS de bout en bout sans VAULT_SKIP_VERIFY
Procédures de recovery	Que faire si vous perdez des unseal keys
Rotation du root token	Le root token initial ne doit pas rester actif
Namespaces (Enterprise)	Isolation multi-tenant
Réplication (Enterprise)	DR et performance multi-région

Glissez pour voir

Documentation de référence

• Production Hardening — Guide officiel de durcissement
• Raft Deployment Guide — Déploiement cluster
• Auto-unseal — Configuration auto-unseal

À retenir

1. Deux méthodes d’installation : package (recommandé) ou binaire manuel
2. Vérifiez toujours les checksums et signatures des binaires téléchargés
3. Mode dev : apprentissage uniquement, jamais en dehors d’un lab local
4. Shamir vs auto-unseal : Shamir pour comprendre, auto-unseal pour exploiter
5. mlock : garder actif en production, désactiver le swap
6. Audit : à activer explicitement dès le premier déploiement
7. Certificats : auto-signé pour le lab, vraie CA pour la production
8. Ce guide est un point de départ, pas une recette production complète

Prochaines étapes

Secrets KV Stocker vos premiers secrets avec le KV store

Authentification Configurer userpass et AppRole

Policies Contrôler qui accède à quoi avec les ACL

PKI Émettre des certificats TLS avec Vault

×

📖 Voir la documentation →