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 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é
Ancrage SOCLE : ce guide met en oeuvre SOCLE-SEC-STO-1, les secrets en coffre chiffrés au repos, et SOCLE-SEC-STO-4, la traçabilité des accès

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 : cumuler le package et un binaire déposé dans /usr/local/bin laisse deux exécutables sur la machine, et c'est celui que PATH trouve en premier qui sera lancé par votre shell, pas forcément celui que systemd démarre. Le tableau oriente le choix sur un seul critère réel : qui prend en charge le cycle de vie (utilisateur système, unité systemd, mises à jour), vous ou le gestionnaire de paquets.

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

Package officiel (recommandé)
Binaire manuel

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

La procédure suit le schéma d'un dépôt APT signé : on récupère d'abord la clé publique HashiCorp, on la stocke dans son propre trousseau (/usr/share/keyrings/), puis on déclare le dépôt en le liant explicitement à cette clé avec signed-by=. C'est ce lien qui garantit qu'un autre dépôt compromis ne pourra pas se faire passer pour HashiCorp. Ne remplacez jamais ce schéma par un apt-key add, obsolète et supprimé des versions récentes d'APT.

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

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

Installer Vault

sudo apt update && sudo apt install -y vault

Vérifier l'installation

vault version
# Vault v2.0.3 (7193f9a48ff6093ca61b3b627a8671e770428ba6), built 2026-06-17T12:39:45Z

# Vérifier que le service existe
systemctl status vault
# ○ vault.service - "HashiCorp Vault - A tool for managing secrets"
#      Loaded: loaded (/usr/lib/systemd/system/vault.service; disabled)
#      Active: inactive (dead)

Le cercle vide et le inactive (dead) sont normaux : le paquet installe le service mais ne le démarre pas, et ne l'active pas au boot. C'est volontaire, la configuration par défaut n'est pas celle que vous voulez. Le démarrage vient plus loin, une fois /etc/vault.d/vault.hcl écrit.

RHEL / Rocky / Fedora

Le principe est le même, mais HashiCorp publie deux dépôts distincts et choisir le mauvais donne des paquets compilés pour une autre version de la glibc. Les distributions de la famille RHEL (RHEL, Rocky, AlmaLinux, CentOS Stream) utilisent le chemin /RHEL/, Fedora utilise /fedora/. Si dnf config-manager renvoie une commande inconnue, installez d'abord dnf-plugins-core.

# RHEL, Rocky, AlmaLinux, CentOS Stream
sudo dnf install -y dnf-plugins-core
sudo dnf config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo

# Fedora : dépôt dédié
# sudo dnf config-manager --add-repo https://rpm.releases.hashicorp.com/fedora/hashicorp.repo

# Installer Vault
sudo dnf install -y vault

# Vérifier
vault version

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

La vérification se fait en deux temps, et les confondre revient à ne rien vérifier du tout. Le fichier SHA256SUMS prouve que l'archive téléchargée n'a pas été altérée en transit ; le fichier SHA256SUMS.sig prouve que ce fichier de sommes vient bien de HashiCorp. Contrôler l'empreinte sans contrôler la signature laisserait un attaquant remplacer les deux fichiers d'un coup.

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

VERSION="2.0.3"
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"

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

Vérifier la signature des checksums

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

Vérifier le checksum du binaire

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

Extraire et installer
Fenêtre de terminal
```
unzip vault_${VERSION}_linux_${ARCH}.zip
sudo mv vault /usr/local/bin/
sudo chmod +x /usr/local/bin/vault

vault version
# Vault v2.0.3 (7193f9a48ff6093ca61b3b627a8671e770428ba6), built 2026-06-17T12:39:45Z
```
Prévoyez la place disque : l'archive pèse environ 170 Mo et le binaire décompressé dépasse 500 Mo. Sur un runner de CI au disque contraint, ou sur une petite VM, c'est un poste à anticiper, d'autant que l'archive et le binaire coexistent le temps de l'extraction.

Créer l'utilisateur et les répertoires

Le package se chargeait de cette étape, ici elle vous revient. L'objectif est que le processus Vault ne tourne jamais en root : un compte système sans shell (--shell /bin/false) ne peut pas être utilisé pour ouvrir une session, même si quelqu'un parvenait à en deviner le mot de passe. Les permissions 700 sur data et logs sont le minimum : ces répertoires contiennent respectivement le stockage chiffré et le journal d'audit, qui trace les chemins des secrets consultés.

# 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

L'unité ci-dessous reprend celle que le package officiel HashiCorp installe, avec le chemin adapté à /usr/local/bin. Quatre points comptent vraiment. LimitMEMLOCK=infinity associé à AmbientCapabilities=CAP_IPC_LOCK autorise Vault à verrouiller sa mémoire pour qu'elle ne parte jamais dans le swap, sans lui donner les privilèges root. LimitCORE=0 interdit les fichiers de core dump, qui contiendraient les secrets en clair. NoNewPrivileges et ProtectSystem limitent ce que le processus peut faire s'il est compromis. Enfin Type=notify : Vault prévient systemd quand il est réellement prêt, si bien qu'un systemctl start en échec renvoie une erreur au lieu d'un succès trompeur. Créez le fichier /etc/systemd/system/vault.service :

[Unit]
Description="HashiCorp Vault - A tool for managing secrets"
Documentation=https://developer.hashicorp.com/vault/docs
Requires=network-online.target
After=network-online.target
ConditionFileNotEmpty=/opt/vault/config/vault.hcl
StartLimitIntervalSec=60
StartLimitBurst=3

[Service]
Type=notify
User=vault
Group=vault
ProtectSystem=full
ProtectHome=read-only
PrivateTmp=yes
PrivateDevices=yes
SecureBits=keep-caps
NoNewPrivileges=yes
# Permettre mlock sans privilèges root
AmbientCapabilities=CAP_IPC_LOCK
CapabilityBoundingSet=CAP_SYSLOG CAP_IPC_LOCK
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
TimeoutStopSec=30
LimitNOFILE=65536
LimitMEMLOCK=infinity
# Pas de core dump : il contiendrait des secrets en clair
LimitCORE=0

[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

Le mode dev n'est pas une version allégée de Vault, c'est le serveur complet avec des raccourcis de configuration. Lisez la colonne de droite comme la liste des protections désactivées : stockage en mémoire, HTTP en clair, déverrouillage automatique et token root affiché. Chacune de ces lignes est exactement ce que vous passerez le reste du guide à mettre en place correctement.

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

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

Le serveur reste au premier plan dans son terminal, il ne faut donc pas le couper. Ouvrez un second terminal : la CLI vault y lit deux variables d'environnement, VAULT_ADDR pour savoir qui contacter et VAULT_TOKEN pour s'authentifier. En mode dev seulement, ce token est celui que vous avez imposé au démarrage.

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

Ces deux commandes écrivent puis relisent un secret dans le moteur KV v2 monté automatiquement sur secret/ par le mode dev. Regardez la sortie du put : Vault répond avec un chemin secret/data/test, pas secret/test. Ce segment data/ est une particularité de KV v2, qui range les valeurs sous data/ et leurs métadonnées sous metadata/. Vous le retrouverez au moment d'écrire vos policies, où il faut utiliser le chemin complet.

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

Si la lecture renvoie bien votre message, l'installation fonctionne. Le reste du guide reprend la même mécanique sur un serveur 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

Architecture cible

Le schéma montre ce que vous allez assembler : un seul processus Vault, son stockage Raft intégré posé sur le disque local, et un listener TLS en façade. Raft mérite un mot, car son nom prête à confusion sur un serveur unique : c'est un moteur de stockage à part entière, qui n'a pas besoin de base de données externe, et qui saura plus tard accueillir d'autres nœuds sans changer de configuration de stockage.

Architecture Vault Server mono-nœud

Fichier de configuration

Le fichier de configuration est écrit en HCL et sa structure est la même quelle que soit la méthode d'installation ; seul son emplacement change. Quatre blocs suffisent ici : le stockage, le listener, les adresses annoncées et le niveau de log. Le point le plus souvent négligé est api_addr : c'est l'adresse que Vault renvoie aux clients et aux autres nœuds, elle doit donc être joignable depuis le réseau, pas depuis le serveur seulement.

Installation package
Installation binaire

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/tls.crt"
  tls_key_file  = "/opt/vault/tls/tls.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"

Contrairement à l'installation par binaire, vous n'avez aucun répertoire à créer : le paquet pose déjà /opt/vault/data et /opt/vault/tls, tous deux appartenant à l'utilisateur vault, le second en 0700. Vérifiez plutôt ce que vous avez reçu :

sudo ls -la /opt/vault/
# drwxr-xr-x. 4 vault vault   29 ... .
# drwxr-xr-x. 2 vault vault    6 ... data
# drwx------. 2 vault vault   36 ... tls

Deux points à connaître sur cette configuration par défaut. Le paquet écrit un /etc/vault.d/vault.hcl qui utilise storage "file", pas raft : le bloc ci-dessus le remplace. Et le répertoire /opt/vault/logs, utile si vous activez l'audit fichier, n'est pas créé, à vous de le poser.

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

Si vous avez installé Vault par le paquet, vous n'avez rien à faire : son unité systemd accorde déjà AmbientCapabilities=CAP_IPC_LOCK et pose LimitMEMLOCK=infinity. Le journal du service le confirme au démarrage :

Mlock: supported: true, enabled: true

Le problème ne se pose donc que sur une installation par binaire, où vous écrivez l'unité vous-même, ou en exécution au premier plan. Devant un mlock: operation not permitted :

Option 1 (recommandée) : Ajouter les capabilities dans systemd, comme le fait l'unité du paquet, avec AmbientCapabilities=CAP_IPC_LOCK

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

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

Démarrer le serveur

enable inscrit le service au démarrage de la machine, start le lance immédiatement. Le troisième appel n'est pas décoratif : avec Type=notify, un service qui affiche active (running) a réellement fini son initialisation. Si vous voyez activating puis un échec, la cause est presque toujours dans la configuration HCL ou les permissions du répertoire de données, et journalctl -u vault -n 50 vous donnera la ligne exacte.

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

Vérifier le statut

Le client vault ne devine pas où joindre le serveur : sans VAULT_ADDR, il tente https://127.0.0.1:8200 et échouera dès que le listener écoute ailleurs. Exportez donc l'adresse, puis indiquez comment valider le certificat. Ces deux variables sont propres à votre shell, pensez à les remettre dans votre profil ou dans un fichier d'environnement si vous administrez le serveur régulièrement.

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

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

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

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é)

Sur un poste de travail, découper la clé maître en plusieurs parts n'apporte rien : vous détenez déjà tout. Une part unique avec un seuil de un raccourcit chaque redémarrage à une seule commande de déverrouillage. Notez tout de même la clé et le root token : le mode persistant, contrairement au mode dev, ne les réaffichera jamais.

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

Pour un environnement partagé (3 sur 5)

Le couple 5 parts / seuil 3 est le réglage de référence, parce qu'il équilibre deux risques opposés. Un seuil trop bas laisse une seule personne rouvrir le coffre ; un seuil égal au nombre de parts rend le déverrouillage impossible dès qu'un détenteur est absent ou perd sa clé. Avec 3 sur 5, il faut la collusion de trois personnes pour ouvrir, et il reste deux clés de marge en cas de perte.

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.

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

Le déverrouillage est cumulatif et sans état côté client : chaque appel dépose une part, et Vault ne reconstitue la clé maître qu'une fois le seuil atteint. Les détenteurs peuvent donc saisir leur part chacun depuis leur poste, il n'est pas nécessaire de rassembler les clés au même endroit. Répétez la commande autant de fois que le seuil l'exige :

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

Déverrouiller n'est pas se connecter. Un Vault descellé refuse toujours toute lecture tant que le client n'a pas présenté un token. Utilisez le root token uniquement pour cette mise en route : sa première tâche devrait être de créer une méthode d'authentification et des policies, puis de se révoquer lui-même avec vault token revoke -self.

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.

Activer l'audit fichier

Un point de comportement à connaître avant d'activer l'audit : si tous les devices d'audit configurés deviennent inaccessibles (disque plein, permissions cassées), Vault cesse de répondre aux requêtes plutôt que de traiter une opération sans la journaliser. C'est un choix délibéré, mais il transforme un disque saturé en indisponibilité complète. HashiCorp recommande d'ailleurs d'activer au moins deux devices en production pour éviter cette panne. Surveillez l'espace disque du répertoire de logs au même titre que le service.

# 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

Le journal d'audit grossit vite, une ligne JSON par requête API, et c'est précisément le fichier qu'il ne faut pas laisser saturer la partition. La configuration ci-dessous conserve 30 jours et compresse les archives. delaycompress évite de compresser le fichier que Vault vient tout juste de fermer, et le postrotate envoie un SIGHUP pour que le processus rouvre son descripteur, sinon il continuerait d'écrire dans le fichier renommé. Créez /etc/logrotate.d/vault :

/opt/vault/logs/*.log {
    daily
    rotate 30
    compress
    delaycompress
    notifempty
    missingok
    su vault vault
    postrotate
        /bin/systemctl reload vault.service
    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

Deux réflexes avant de dérouler ce tableau. D'abord vérifier que le client vise la bonne adresse : echo $VAULT_ADDR explique à lui seul une bonne moitié des connection refused. Ensuite lire journalctl -u vault -n 50, où les erreurs de configuration HCL apparaissent en clair avec le numéro de ligne fautif. Le tableau traite les cas restants, ceux où le service tourne mais refuse de répondre.

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

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

Côté SOCLE, installer le coffre ne prouve rien sur le cycle de vie des secrets qu'il abrite. Toute la famille rotation reste ouverte après ce guide : la politique de rotation par criticité et les TTL (SOCLE-SEC-ROT-1), le test de révocation d'urgence (SOCLE-SEC-ROT-3) et la détection de fuite (SOCLE-SEC-ROT-4) se construisent avec les policies et les moteurs de secrets dynamiques, pas avec l'installation.

À retenir

Deux méthodes d'installation : package (recommandé) ou binaire manuel
Vérifiez toujours les checksums et signatures des binaires téléchargés
Mode dev : apprentissage uniquement, jamais en dehors d'un lab local
Shamir vs auto-unseal : Shamir pour comprendre, auto-unseal pour exploiter
mlock : garder actif en production, désactiver le swap
Audit : à activer explicitement dès le premier déploiement
Certificats : auto-signé pour le lab, vraie CA pour la production
Ce guide est un point de départ, pas une recette production complète
Preuve attendue par le SOCLE : le serveur Raft initialisé et descellé prouve SOCLE-SEC-STO-1, secrets en coffre chiffrés au repos ; le fichier d'audit prouve SOCLE-SEC-STO-4, accès tracés ; le couple scellement plus audit couvre la part vérifiable ici de SOCLE-SEC-STO-5, la séparation des rôles restant à construire avec les policies

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