HashiCorp Vault pour secrets DevOps

À la fin de ce tutoriel, vous saurez expliquer pourquoi HashiCorp Vault remplace les secrets dans Git, poser un lab Docker (KV v2 + policy + AppRole), et brancher un pattern CI/CD sans token root — avec la region lab ca-central-1 quand le cloud entre en jeu.

Niveau : Intermédiaire · Temps estimé : 55–75 min · Versions cibles : Vault 1.17+ · Vault CLI · Docker · GitHub Actions (concept) · Dernière vérification : 2026-09-11 · Region : ca-central-1

Slug : wow-vault-secrets-devops · Série : WOW (11/50) · Mot-clé SEO : hashicorp vault · Publish : HOLD

← Précédent : Conftest dans le CI · → Suivant : SOPS + age · Aussi : Secrets Kubernetes · External Secrets Operator

Prérequis

• Bases Linux / shell et Git — Linux · Git
• Notions CI/CD (pipeline, variables) — DevOps
• Docker local pour le lab Vault en mode dev (jetable)
• Optionnel : cluster Kubernetes pour le teaser ESO — Kubernetes
• Compte AWS de lab si vous liez OIDC plus tard — profil lab, region ca-central-1

Coût estimé : 0 € pour le lab Docker Vault -dev. Aucune ressource AWS obligatoire. Si vous créez du cloud, restez Free Tier et détruisez en fin de session.

docker --version
vault --version || echo "CLI Vault optionnelle (sinon docker exec)"
export AWS_DEFAULT_REGION=ca-central-1

Ce que nous allons construire

HashiCorp Vault — secrets DevOps (WOW 11/50)
  ├── Pourquoi Vault (vs Git / env / K8s Opaque)
  ├── Concepts : seal, auth, policies, KV v2
  ├── Lab Docker : vault server -dev
  ├── KV v2 + policy least privilege + AppRole CI
  ├── Teaser K8s (ESO) + Vault vs SOPS vs cloud
  └── Quiz + FAQ + maillage WOW

(Schéma — alt : « CI obtient un secret via AppRole Vault ; apps K8s via External Secrets ; lab ca-central-1 ».)

Étape 1 — Pourquoi Vault en DevOps ?

Un .env commité, une variable CI longue durée ou un Secret Kubernetes Opaque (base64) ne constituent pas une gestion de secrets. Base64 n’est pas du chiffrement.

HashiCorp Vault centralise l’accès avec :

Capacité	Intérêt DevOps
Stockage chiffré	Secrets hors Git et hors image
Policies	Least privilege par rôle / équipe
Auth methods	AppRole, Kubernetes, JWT/OIDC, cloud IAM
KV v2	Versions + soft-delete
Secrets dynamiques	Creds DB / cloud à TTL court (aperçu)
Audit	Qui a lu quoi, quand

Objectif DEH : zéro secret long dans le dépôt, rotation, audit, chemins reproductibles pour CI et runtimes.

Étape 2 — Concepts clés

Terme	Sens pratique
Seal / unseal	Vault démarre scellé ; clés (ou auto-unseal cloud) ouvrent le coffre
Root token	Super-admin — jamais en CI ni en prod longue durée
Auth method	Comment une machine / un humain prouve son identité
Policy	Droits du token obtenu (read/write sur des paths)
Secrets engine	Backend (KV, database, AWS…) monté sous un path
KV v2	Key-Value versionné (path typique secret/)
Lease / TTL	Durée de vie d’un secret ou token dynamique

En lab -dev, Vault est déjà unsealed avec un root token au démarrage — utile pour apprendre, interdit en production.

Étape 3 — Lab Docker : Vault en mode dev

Lab jetable, placeholders uniquement.

docker run --rm -d --name vault-lab   -p 8200:8200   -e VAULT_DEV_ROOT_TOKEN_ID=root-lab-only   -e VAULT_DEV_LISTEN_ADDRESS=0.0.0.0:8200   hashicorp/vault:1.17

export VAULT_ADDR='http://127.0.0.1:8200'
export VAULT_TOKEN='root-lab-only'
vault status
vault secrets list

Attendu : Sealed false, mode development. Le token root-lab-only est un placeholder de lab. Sur -dev, KV v2 est souvent déjà monté sur secret/ ; sinon :

vault secrets enable -path=secret kv-v2

Étape 4 — KV v2 : écrire, lire, versionner

Secret d’application fictif (jamais de vrais credentials) :

vault kv put secret/apps/payments/config   db_user=demo_user   db_password=CHANGE_ME_lab_only   api_token=PLACEHOLDER_TOKEN_NOT_REAL

vault kv get secret/apps/payments/config

vault kv put secret/apps/payments/config   db_user=demo_user   db_password=CHANGE_ME_rotated_lab   api_token=PLACEHOLDER_TOKEN_NOT_REAL

vault kv metadata get secret/apps/payments/config

KV v2 crée une nouvelle version à chaque put. Documentez le path (secret/apps/<service>/config) dans le README du service template — pas la valeur.

Étape 5 — Policy least privilege

Le root token lit tout. Une app ou un job CI ne doit lire que son path.

Fichier policy-payments-read.hcl :

# Lecture seule sur le secret payments (lab)
path "secret/data/apps/payments/*" {
  capabilities = ["read"]
}

path "secret/metadata/apps/payments/*" {
  capabilities = ["read", "list"]
}

Attention KV v2 : données via secret/data/..., métadonnées via secret/metadata/....

vault policy write payments-read policy-payments-read.hcl
vault policy list
vault policy read payments-read

Étape 6 — AppRole pour la CI (pas de root)

AppRole : auth machine-to-machine. La CI reçoit role_id + secret_id (ou, mieux ensuite, JWT/OIDC). Lab minimal :

vault auth enable approle

vault write auth/approle/role/ci-payments   token_policies="payments-read"   token_ttl=15m   token_max_ttl=30m   secret_id_ttl=24h

vault read auth/approle/role/ci-payments/role-id
vault write -f auth/approle/role/ci-payments/secret-id

Login local (placeholders) :

export ROLE_ID='CHANGE_ME_role_id'
export SECRET_ID='CHANGE_ME_secret_id'

vault write auth/approle/login   role_id="$ROLE_ID"   secret_id="$SECRET_ID"

Vous obtenez un token court limité à payments-read. Modèle à retenir pour GitHub Actions / GitLab CI : jamais VAULT_TOKEN=root dans les secrets du dépôt.

Flux pipeline : login AppRole → token TTL court → vault kv get du path service → injection runtime sans echo dans les logs. Si la CI assume aussi un rôle AWS, gardez ca-central-1 et préférez OIDC aux access keys longues.

Étape 7 — Runtime Kubernetes (teaser)

Pattern	Idée
Agent Injector	Init/sidecar injecte des fichiers dans le Pod
External Secrets Operator	Sync Vault → Secret K8s natif
CSI Secrets Store	Volume CSI monté depuis Vault

Détail ESO : External Secrets Operator. Le Secret Opaque reste un cache ; la source de vérité est Vault (ou un store cloud). Rappel limites Opaque : Secrets Kubernetes.

Étape 8 — Vault vs SOPS vs cloud stores

Solution	Quand l’utiliser
Vault	Multi-apps, policies, audit, dynamiques, CI + K8s
SOPS + age	Secrets chiffrés dans Git, petites équipes, GitOps — wow-sops-age-git
AWS Secrets Manager / SSM	Stack surtout AWS, IAM natif, region ca-central-1
Azure Key Vault	Stack Azure / ADO — variables Key Vault

Chez DEH, Vault est le hub quand plusieurs runtimes partagent les mêmes policies. SOPS reste excellent pour un bootstrap GitOps sans serveur.

Étape 9 — Check-list production (hors lab -dev)

1. Pas de mode -dev ; HA + storage durable
2. Auto-unseal (KMS ca-central-1 ou équivalent)
3. Root token révoqué après bootstrap
4. Policies par service + TTL courts AppRole / CI
5. Audit device + rotation documentée
6. Zéro secret dans les logs ; break-glass + offboarding

Erreurs fréquentes

Erreur	Impact	Correction
Root token en CI	Compromission totale	AppRole / JWT + policy étroite
Policy sans path secret/data/	Accès KV v2 cassé	Paths secret/data/...
Vault -dev en prod	Perte + pas d’audit réel	Cluster HA + unseal propre
echo du secret dans le job	Fuite logs / artefacts	Fields ciblés, masquage CI
Opaque seul = « Vault »	Pas de rotation centrale	ESO / injector + source Vault
Secret_id AppRole illimité	Accès prolongé si vol	TTL + wrapping + rotation

Quiz (5 questions)

1. Base64 dans un Secret Kubernetes Opaque signifie :
– A. Chiffrement fort at-rest applicatif
– B. Encodage seulement — pas une gestion de secrets
– C. Rotation automatique Vault

2. En CI, le modèle préféré est :
– A. Root token longue durée dans GitHub Secrets
– B. AppRole (ou JWT) + policy least privilege + TTL court
– C. Mot de passe root SSH sur le runner

3. En KV v2, le path de lecture des données est typiquement :
– A. secret/metadata/... uniquement
– B. secret/data/...
– C. sys/raw/...

4. Region lab AWS imposée dans la série DEH :
– A. us-east-1
– B. ca-central-1
– C. eu-west-3

5. SOPS + age est surtout utile pour :
– A. Remplacer Kubernetes
– B. Chiffrer des secrets dans Git sans serveur Vault
– C. Remplacer TLS

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B

FAQ

Vault remplace-t-il les Secrets Kubernetes ?

Non. Vault est souvent la source ; le Secret K8s (via ESO / injector) est un mécanisme d’injection. Opaque seul ne remplace pas Vault.

Puis-je garder des secrets dans Git « pour GitOps » ?

Oui avec SOPS + age (chiffré). Clair dans Git = incident. Voir wow-sops-age-git.

AppRole ou OIDC/JWT pour GitHub Actions ?

AppRole fonctionne. En 2026, JWT/OIDC vers Vault (sans secret_id longue durée) est souvent plus propre. Le lab AppRole enseigne policies + TTL ; migrez ensuite.

Pourquoi ca-central-1 dans un tuto Vault ?

Standard lab DevOps Elastic Hayway dès qu’AWS (KMS auto-unseal, OIDC) entre dans le parcours — cohérence FinOps et IAM entre tutos.

Vault vs AWS Secrets Manager ?

Secrets Manager pour un paysage AWS-only ; Vault pour multi-runtime et policies unifiées. Les deux peuvent coexister via ESO.

Combien de policies au démarrage ?

Une policy par service (read sur son path) + une policy admin séparée. Évitez les capabilities larges « pour aller vite ».

Pour aller plus loin

• SOPS + age (WOW 12) · External Secrets Operator (WOW 13)
• Secrets Kubernetes · Key Vault ADO
• Conftest CI · Platform Engineering · DevSecOps

Maillage série WOW

← Précédent	Conftest dans le CI
→ Suivant	SOPS + age : secrets dans Git
Aussi	ESO · OPA · DevSecOps · IDP

---

Meta publication (SEO)

• Title SEO : HashiCorp Vault pour secrets DevOps (guide FR 2026)
• Meta description : HashiCorp Vault pour secrets DevOps : KV v2, policies, AppRole CI, lab Docker, patterns K8s. FAQ et quiz — region lab ca-central-1.
• Focus keyword : hashicorp vault
• Secondary : vault secrets devops, vault approle, vault kv v2
• URL cible : https://devopelastichayway.com/tutoriels/wow-vault-secrets-devops/
• Publish : HOLD (draft — push centralisé Maître) · slug wow-vault-secrets-devops