Ce module met un secret dans un coffre, fait prouver à chaque client qui il est, puis n'ouvre que le chemin strictement nécessaire. HashiCorp Vault en est l'implémentation : il chiffre ce qu'on lui confie, délivre un token après une authentification réussie, et ne répond que si une policy l'autorise. Il s'adresse à qui connaît déjà le cycle de vie d'un secret et veut passer du principe au geste, en trois leçons qui se suivent : Vault KV, l'authentification puis les policies.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Décider si un coffre Vault se justifie pour votre contexte, ou si un outil plus léger suffit
- Situer l'authentification, les policies et les secrets engines dans la chaîne d'accès de Vault
- Comprendre pourquoi les trois leçons se suivent dans l'ordre stocker, authentifier, scoper
- Repérer ce que coûte l'exploitation du coffre lui-même, et où le module facultatif le détaille
- Relier le module aux exigences SOCLE-SEC-STO sur le stockage, les accès scopés et leur traçabilité
Pourquoi ce module vient après le cycle de vie ?
Section intitulée « Pourquoi ce module vient après le cycle de vie ? »Le module précédent a posé le cycle de vie d'un secret en huit étapes, le choix entre secret statique, dynamique ou identité fédérée et le chiffrement en enveloppe qui protège le coffre lui-même. Il disait où un secret doit vivre à l'étape de stockage. Ce module construit ce lieu : le coffre, la porte d'entrée (l'authentification) et la règle d'ouverture (la policy).
Il précède les secrets dynamiques pour une raison mécanique. Un secret dynamique est fabriqué à la demande par Vault, mais le client qui le réclame passe par la même chaîne qu'une lecture KV : il s'authentifie, reçoit un token, et une policy décide du chemin ouvert. Sans cette chaîne, on ne saurait ni à qui délivrer un identifiant éphémère, ni l'empêcher d'en demander un pour la production. Le coffre et ses accès scopés sont donc le prérequis commun de tout ce qui suit.
Quel fil relie les trois leçons ?
Section intitulée « Quel fil relie les trois leçons ? »Chaque leçon répond à une question, et la réponse de l'une devient l'entrée de la suivante. La première fixe les chemins sous lesquels vivent les secrets, la deuxième fait émettre un token à un humain ou à une machine, la troisième attache à ce token une policy qui nomme ces chemins. L'arborescence choisie dans KV détermine donc les policies, et les policies s'attachent aux méthodes d'authentification : l'ordre n'est pas décoratif.
| Leçon | Question posée | Ce que vous produisez |
|---|---|---|
| Vault KV | Où vit le secret, sous quel chemin ? | Un mount KV v2, des secrets versionnés rangés par application et par environnement |
| Authentification | Qui demande ? | Un compte userpass, un rôle AppRole, un token à durée de vie courte |
| Policies | Que peut faire ce token, et sur quel chemin ? | Une policy HCL chargée, rattachée, testée avec un refus attendu |
Une leçon facultative complète ce module : Vault Transit, qui chiffre une donnée sans jamais confier la clé à l'application. Il suit la même chaîne d'accès, avec un moteur différent.
Quand Vault est-il le bon coffre ?
Section intitulée « Quand Vault est-il le bon coffre ? »Vault est un outil puissant mais complexe, et la première décision n'est pas technique : y a-t-il un besoin qui justifie cette complexité ? Il devient pertinent dès qu'au moins un des besoins suivants apparaît. La colonne de droite dit ce que Vault apporte que le reste du marché apporte moins bien.
| Besoin | Pourquoi Vault excelle |
|---|---|
| Secrets dynamiques | Credentials base de données, cloud, SSH générés à la demande avec TTL |
| PKI interne | Autorité de certification intégrée, certificats courts (heures/jours) |
| Chiffrement applicatif | Transit : l'application n'a jamais accès aux clés de chiffrement |
| Audit fort | Journal complet de qui accède à quoi, quand, pour quelle raison |
| Multi-équipes | Isolation des secrets par équipe/environnement avec policies ACL |
| Rotation / révocation | Révocation instantanée, rotation automatique des credentials |
| Intégration Kubernetes | Auth native via ServiceAccount, injection de secrets |
| Fédération d'identité | Authentification unifiée OIDC, LDAP, cloud providers |
À l'inverse, certaines situations apportent plus de complexité que de valeur. Pour une petite équipe, un outil plus léger rend souvent plus de service, car le coût opérationnel de Vault dépasse le bénéfice. Le tableau donne, pour chaque situation, l'alternative la plus simple à examiner d'abord.
| Situation | Alternative plus simple |
|---|---|
| Quelques secrets d'équipe | Gestionnaire de mots de passe (Bitwarden, 1Password) |
| Secrets CI/CD simples | Variables secrètes GitLab/GitHub, AWS Secrets Manager |
| Équipe < 10 personnes, mono-env | SOPS + Git, Infisical, Doppler |
| Pas de budget ops dédié | Solution managée (HCP Vault, Infisical Cloud) |
| Besoin ponctuel de certificats | Let's Encrypt, Certbot |
Entre les deux, le choix de la solution dépend du profil. Vault et son fork OpenBao deviennent le bon choix dès qu'apparaissent le multi-équipes, la PKI interne ou le chiffrement applicatif ; l'édition Enterprise se justifie pour les namespaces, la réplication et la conformité stricte.
| Profil | Solution recommandée | Pourquoi |
|---|---|---|
| Petite équipe (< 10 dev) | Infisical, Doppler, SOPS | Moins de complexité opérationnelle |
| Startup / équipe moyenne | Vault CE ou OpenBao | Bon rapport puissance/complexité |
| Plateforme interne multi-équipes | Vault Enterprise ou OpenBao | Namespaces, isolation |
| Kubernetes-first | External Secrets + (Vault ou OpenBao) | Intégration native |
| PKI interne / mTLS | Vault CE ou OpenBao | Engine PKI complet |
| Chiffrement applicatif | Vault Transit | Les clés ne quittent jamais Vault |
| Compliance stricte | Vault Enterprise | MFA, Sentinel, Control Groups |
| Open source pur requis | OpenBao | Licence MPL 2.0 |
Que coûte un coffre qu'il faut opérer ?
Section intitulée « Que coûte un coffre qu'il faut opérer ? »Vault n'est pas un simple coffre-fort : c'est un composant d'infrastructure dont une panne ou une mauvaise configuration touche toutes les applications qui en dépendent. Le tableau ci-dessous est le vrai coût de Vault, celui qui n'apparaît pas dans un tutoriel en mode dev. Chaque ligne est une tâche récurrente à outiller, pas une case cochée une fois. Regardez en priorité l'initialisation, l'unsealing et le stockage : elles conditionnent la capacité à redémarrer le service après une panne.
| Composant | Ce que vous devez gérer |
|---|---|
| Initialisation | Générer et sécuriser les clés de déverrouillage (unseal keys) |
| Unsealing | Déverrouiller Vault après chaque redémarrage (manuel ou auto-unseal) |
| Stockage | Configurer et maintenir le backend (Raft intégré recommandé) |
| Haute disponibilité | Cluster 3+ nœuds pour la tolérance aux pannes |
| Sauvegardes | Snapshots réguliers du storage Raft |
| Rotation des clés | Rotation périodique de la clé de chiffrement maître |
| Audit | Configurer et monitorer les audit devices (fichier, syslog, socket) |
| Monitoring | Métriques Prometheus, alertes sur les échecs d'auth, expirations |
| Policies | Écrire et maintenir les ACL pour chaque équipe/application |
| TLS | Certificats pour l'API Vault (obligatoire en production) |
Ces tâches sont l'objet du dernier module de la formation, facultatif : il vise l'exploitant du coffre plutôt que celui qui y lit des secrets. Il couvre l'installation, l'auto-unseal et les recovery keys (qui évitent l'intervention manuelle après chaque redémarrage) et l'exploitation en production. Il porte aussi trois pages de choix : les éditions CE et Enterprise, la licence BSL 1.1 adoptée en août 2023 (usage interne autorisé, offre managée concurrente interdite) et Vault face à OpenBao, le fork maintenu par la Linux Foundation sous licence MPL 2.0.
Comment Vault protège-t-il un secret ?
Section intitulée « Comment Vault protège-t-il un secret ? »Vault repose sur quatre composants qui interagissent pour sécuriser vos secrets. Le schéma ci-dessous suit le flux d'accès à un secret, du client jusqu'à la valeur déchiffrée. Deux points méritent l'attention en le lisant. Toute requête traverse d'abord une auth method, qui délivre un token, puis une policy, qui décide de ce que ce token peut faire ; le secret n'est atteint qu'après ces deux barrières. Et rien ne fonctionne tant que le barrier, la couche de chiffrement, n'est pas descellé.
Les trois leçons du module occupent les trois maillons du milieu : KV est un secrets engine, l'authentification est l'auth method, les policies sont la couche ACL qui les sépare. Le système d'identité, lui, mérite un mot parce qu'il est souvent sous-estimé : Vault maintient des entities qui consolident les différentes méthodes d'authentification.
- Entity : représente une personne ou une application unique
- Alias : lie une entity à une auth method (alice via userpass et alice via OIDC forment la même entity)
- Group : regroupe des entities pour leur appliquer des policies communes
Cela donne une vision unifiée des accès même si vous mélangez plusieurs
méthodes : userpass pour le développement, OIDC pour les employés, Kubernetes
pour les pods. Reste l'état sealed : Vault démarre scellé et refuse toute
opération, car ses données sont chiffrées par une clé maître elle-même
chiffrée. Le mode Shamir, par défaut, divise cette clé en N parts dont M
suffisent à la reconstituer ; l'auto-unseal confie la clé à un service
externe (KMS, Transit) pour éviter les interventions manuelles.
Quels secrets engines pour quels besoins ?
Section intitulée « Quels secrets engines pour quels besoins ? »Un secrets engine est un module que vous activez sur un chemin de montage donné et qui définit comment Vault traite les secrets à cet endroit. Vous n'activez que les engines dont vous avez l'usage, et chacun est monté sur un chemin distinct que les policies contrôlent séparément. Vault distingue deux familles : les secrets statiques, que vous déposez et qui restent identiques tant que vous ne les changez pas, avec tous les problèmes que cela pose, et les secrets dynamiques, générés à la demande avec une durée de vie limitée, puis supprimés par Vault à l'expiration du bail.
Repérez d'abord la colonne Famille : elle dit si l'engine stocke une valeur
figée (Statique), en fabrique une jetable (Dynamique) ou transforme une
donnée sans la stocker (Chiffrement). Le passage du statique au dynamique est le vrai
gain de Vault : Database, PKI, SSH et les engines cloud suppriment le
credential partagé et permanent qui traîne dans vos configurations.
| Engine | Famille | Ce qu'il fait concrètement |
|---|---|---|
| KV v2 | Statique | Votre coffre-fort classique : stockez n'importe quel secret avec versioning (10 dernières versions conservées) |
| Transit | Chiffrement | Vault chiffre/déchiffre vos données sans jamais vous donner la clé. Votre app envoie du texte clair, reçoit du chiffré. |
| Database | Dynamique | Crée un user PostgreSQL/MySQL/MongoDB à la demande, le supprime automatiquement après expiration |
| PKI | Dynamique | Fabrique des certificats TLS signés par votre CA interne, avec la durée que vous voulez (1 heure, 30 jours...) |
| SSH | Dynamique | Signe les clés SSH ou génère des mots de passe OTP pour accéder à vos serveurs |
| AWS/Azure/GCP | Dynamique | Génère des credentials cloud temporaires (IAM user, service account...) |
| Cubbyhole | Statique | Coffre-fort personnel lié à votre token, personne d'autre ne peut y accéder, même les admins |
Le second tableau prend le problème par l'autre bout : partez de votre besoin
réel, il renvoie vers l'engine adapté. Une règle de lecture aide à décider
vite. Si le secret vous est imposé de l'extérieur (clé API d'un fournisseur
tiers), c'est du statique en KV v2, et c'est l'objet de la première leçon.
Dès que Vault peut créer et détruire le credential lui-même, préférez
l'engine dynamique correspondant, qui élimine le mot de passe partagé.
| Votre besoin | Engine recommandé | Pourquoi |
|---|---|---|
| Stocker des clés API tierces | KV v2 | Secrets statiques imposés par le fournisseur |
| Accès base de données pour vos apps | Database | Plus de mot de passe partagé, rotation automatique |
| Chiffrer des données sensibles (RGPD) | Transit | Vos développeurs n'ont jamais accès aux clés |
| Certificats TLS internes (mTLS) | PKI | Certificats courts, révocation facile |
| Accès SSH à vos serveurs | SSH | Plus de clés SSH qui traînent, accès audité |
| Credentials AWS temporaires | AWS | Plus de access keys permanentes dans les configs |
Comment un client prouve-t-il son identité ?
Section intitulée « Comment un client prouve-t-il son identité ? »Avant d'accéder à un secret, un client doit prouver qui il est, et la méthode dépend de sa nature. Pour un humain, c'est simple : un mot de passe ou le SSO de l'entreprise. Une machine, elle, ne peut pas taper de mot de passe : elle prouve son identité par son environnement. Le critère de choix est donc la nature de celui qui s'authentifie, et la colonne de droite décrit le mécanisme de vérification.
| Qui s'authentifie | Méthode recommandée | Comment ça marche |
|---|---|---|
| Développeur en local | Userpass | Login/mot de passe classique, simple pour les tests |
| Employé en entreprise | OIDC ou LDAP | SSO via Keycloak, Okta, Azure AD, ou Active Directory |
| Pipeline CI/CD | AppRole | role_id en variable, secret_id généré à chaque run |
| Pod Kubernetes | Kubernetes auth | ServiceAccount token vérifié par Vault |
| Instance EC2/VM cloud | AWS/Azure/GCP auth | L'identité machine du cloud provider |
| Serveur on-premise | AppRole ou TLS certs | Selon votre infrastructure |
La leçon d'authentification traite les deux méthodes qui ne dépendent d'aucune
infrastructure tierce : userpass et AppRole, où l'application reçoit un
role_id (son identité) et un secret_id (un mot de passe jetable). Les
méthodes Kubernetes et cloud illustrent un concept plus large, l'identité de
workload : au lieu de distribuer un secret, la machine prouve qui elle est
grâce à son environnement. La formation y consacre un module entier, à partir de
l'identité machine
et du courtier d'identité.
Reste une question que tout mécanisme à secret jetable pose : comment donner le
premier secret à l'application, sans qu'il circule en clair ? C'est le
problème du secret zéro. AppRole le
réduit avec le response wrapping, où le secret_id est enveloppé dans un
token à usage unique qui expire en quelques minutes ; la leçon le met en
pratique. Les tokens Vault fonctionnent aussi seuls, mais il faut les créer et
les distribuer à la main : avec 50 microservices, cela devient ingérable, et
c'est pourquoi on laisse les applications s'authentifier elles-mêmes.
Comment une policy limite-t-elle l'accès ?
Section intitulée « Comment une policy limite-t-elle l'accès ? »Une fois authentifié, que peut faire le client ? C'est le rôle des policies, qui associent des chemins à des capabilities, c'est-à-dire des actions autorisées. Le mécanisme central est le refus par défaut : Vault n'accorde que ce qui est écrit, tout le reste est interdit. Dans l'exemple ci-dessous, l'équipe a les pleins droits sur les secrets de développement, la lecture seule sur la pré-production, et aucun accès à la production, puisque ce chemin n'apparaît nulle part.
# Policy pour l'équipe développementpath "secret/data/dev/*" { capabilities = ["create", "read", "update", "delete", "list"]}
# Lecture seule sur staging (pas de modification en pré-prod)path "secret/data/staging/*" { capabilities = ["read", "list"]}
# Aucun accès à la production : ce qui n'est pas explicitement# autorisé est refuséLe * final couvre tout ce qui suit le préfixe ; la leçon sur les policies
détaille les huit capabilities, la règle qui départage deux chemins qui se
chevauchent, et la manière de tester une policy avant de la confier à un
pipeline. Ce qu'il faut retenir ici : l'accès se pense par rôle métier et
par chemin, jamais par personne, et un deny explicite ne sert que pour les
exceptions.
À retenir
Section intitulée « À retenir »- Un coffre n'a de valeur que s'il est atteint par une chaîne complète : authentification, token, policy, engine, stockage chiffré
- Les trois leçons se suivent : KV fixe les chemins, l'authentification émet le token, les policies nomment les chemins ouverts à ce token
- Vault est puissant mais exigeant : évaluez si vous avez les ressources pour l'opérer, ou si un outil plus léger suffit
- Statique ou dynamique : KV v2 pour ce qui vous est imposé, un engine dynamique dès que Vault peut créer et détruire le credential
- Refus par défaut : une policy n'accorde que ce qu'elle nomme, l'accès se pense par rôle métier
- Identity system : consolide les identités de plusieurs auth methods en une entity
- Le coffre lui-même se protège : scellement, auto-unseal, audit et sauvegardes sont détaillés dans le module facultatif d'exploitation
- Preuve attendue par le SOCLE : les secrets sont en coffre chiffrés au repos, les accès scopés au strict nécessaire et tracés (voir SOCLE-SEC-STO)
FAQ : questions fréquentes
Section intitulée « FAQ : questions fréquentes »Ces réponses courtes traitent les questions de décision qui reviennent le plus avant d'adopter Vault : le choix entre édition CE et Enterprise, la portée de la licence BSL, le positionnement de l'alternative OpenBao et le fonctionnement des secrets dynamiques.
sudo apt install vault
vault version
vault server -dev, tout en mémoire, non sécurisé). En production, configurez un backend Raft et l'auto-unseal, puis initialisez avec vault operator init. Le guide détaille chaque étape : Installer Vault.