Chapitre 3. Présentation de HashiCorp Vault

Objectifs pédagogiques¶

Situer Vault : histoire, éditions, gouvernance. Expliquer ses trois principes de conception et leurs conséquences. Citer ses cas d'usage. Nommer les composants de son architecture. Énoncer ce qu'il est et ce qu'il n'est pas. Le comparer aux alternatives et identifier les cas où il est disproportionné.

Prérequis¶

Chapitres 1 et 2. Ce chapitre confronte Vault à la grille du chapitre 2.

Cours¶

3.1 Repères : histoire, éditions, gouvernance¶

Vault est publié par HashiCorp en 2015, dans une gamme d'outils partageant une même philosophie : serveurs pilotés par API, configuration déclarative, automatisation comme cas nominal.

Elles prennent trois formes. Vault Community Edition, le binaire librement disponible, périmètre de ce cours, qui contient l'intégralité du cœur : moteurs, méthodes d'authentification, policies, stockage intégré Raft, Auto Unseal, Transit Seal. Vault Enterprise, qui ajoute la réplication, les namespaces, le seal matériel, les control groups et les snapshots automatiques. HCP Vault, l'offre managée, qui échange la charge d'exploitation contre un transfert de confiance vers l'opérateur.

Trois éléments de gouvernance appartiennent au dossier de décision. En août 2023, HashiCorp a changé la licence de ses produits, dont Vault à partir de la version 1.15 : de la licence libre MPL 2.0 vers la Business Source License, à sources disponibles, qui restreint essentiellement la fourniture de services concurrents. Ce changement a provoqué la création d'OpenBao, un fork placé sous gouvernance de fondation. L'acquisition de HashiCorp par IBM a été finalisée début 2025.

3.2 Les principes de conception¶

API d'abord. Vault est un serveur exposant une API HTTP ; la ligne de commande et l'interface web n'en sont que des clients. Conséquence pour l'administrateur : tout ce qu'il fait à la main est scriptable à l'identique, et aucune opération n'est réservée à un outil graphique. Conséquence pour l'attaquant : la surface est l'API, toute l'API, rien que l'API, ce qui la rend énumérable, filtrable et journalisable en un point unique.

Tout est chemin. Toute ressource et toute opération est adressée par un chemin, qu'il s'agisse de secrets, d'authentification ou d'administration. Conséquence majeure : l'autorisation s'exprime dans une grammaire unique, des capacités sur des chemins, qui couvre uniformément tout le système. Le moindre privilège devient exprimable partout avec le même outil.

Sécurité par défaut. Trois comportements inversent les habitudes. Le refus par défaut : un token sans policy ne peut rien, on écrit ce qu'on accorde au lieu de restreindre ce qui est ouvert. Le démarrage scellé : le serveur ne peut pas déchiffrer ses propres données sans une opération explicite, l'état sûr est l'état initial. Le chiffrement non optionnel du stockage, avec TLS attendu côté écoute.

3.3 Les grands cas d'usage¶

Cinq usages couvrent l'essentiel des déploiements, et les cinq seront construits dans ce cours.

Le coffre central de secrets statiques. Remplacer fichiers, variables et partages par une source unique, avec authentification, autorisation et trace. Le nombre de copies chute, l'imputabilité apparaît.

Les secrets dynamiques. Des credentials créés à la demande pour un consommateur précis, avec une durée courte et une révocation réelle. C'est le cas d'usage qui applique le principe 2.10.

Le chiffrement comme service. Les applications font chiffrer et déchiffrer sans jamais détenir de clé.

La PKI interne. Émettre des certificats à la demande, courts et nominatifs, plutôt que de partager un certificat wildcard.

L'identité machine. Fournir aux applications, pods et pipelines une identité vérifiable et des droits associés, ce qui traite le secret zéro.

3.4 Architecture : premier survol¶

   client --> [ API HTTP ] --> authentification --> policies --> routage
                                                                   |
                                       +---------------------------+
                                       v
                            [ montages : moteurs de secrets, methodes d'auth ]
                                       |
                                  [ barriere ]  chiffre tout
                                       v
                                  [ stockage ]

Une requête entre par l'API, est rattachée à une identité, confrontée aux droits de cette identité, puis routée vers le composant monté sur le chemin visé. Toute donnée persistée traverse la barrière, qui chiffre systématiquement : le stockage ne voit jamais de clair.

Carte des termes, à connaître avant la partie II. Mount : installation d'un composant sur un chemin. Secrets engine : composant monté gérant une famille de secrets. Auth method : composant qui vérifie des preuves d'identité et délivre des tokens. Policy : règles d'autorisation, capacités sur des chemins. Token : matérialisation d'une authentification réussie. Lease : bail d'un secret ou d'un token, avec durée, renouvellement et révocation. Seal : mécanisme protégeant la clé racine ; scellé, Vault ne se déchiffre pas. Barrière : couche chiffrant tout ce qui part au stockage. Audit device : destination du journal de toutes les requêtes.

3.5 Ce que Vault est, et ce qu'il n'est pas¶

Vault implémente les exigences du chapitre 2. Identités individuelles et authentification multiple (2.2) : les méthodes d'authentification et la couche Identity. Moindre privilège exprimable et vérifiable (2.3) : les policies sur chemins, avec refus par défaut. Rotation et révocation conçues (2.4) : les baux et les moteurs dynamiques. Traçabilité (2.5) : les dispositifs d'audit. Quorum (2.6) : le scellement de Shamir. Racine de confiance désignable (2.9) : le mécanisme de seal.

Cinq limites sont aussi nettes que ces forces.

Vault n'est pas un HSM. Les clés vivent dans la mémoire d'un processus, avec les garanties d'un logiciel. Le seal matériel de l'édition Enterprise change ce point, pas l'édition Community.

Vault n'est pas un gestionnaire de mots de passe. Il ne sert pas les usages humains quotidiens.

Vault n'est pas un IAM. Il ne gère pas le cycle de vie des identités humaines ; il en consomme.

Vault n'est pas une solution de prévention de fuite de données. Il ne surveille pas ce qui sort du système d'information.

Vault ne protège pas un secret après sa livraison. C'est le point capital : au-delà de la livraison, le secret vit dans la mémoire et les pratiques du client, hors de portée de tout contrôle amont. Trois conséquences pratiques : la sécurisation des consommateurs fait partie du projet ; les durées courtes sont la mitigation réaliste ; le chiffrement comme service est la parade ultime pour les clés, puisqu'il ne livre pas la clé.

3.6 Le paysage : alternatives et positionnement¶

Les gestionnaires de secrets des clouds. Dans leur cloud, ils sont excellents : intégration native à l'IAM de la plateforme, ce qui résout le secret zéro par construction pour les charges de ce cloud, aucune infrastructure à exploiter, haute disponibilité fournie. Leurs limites : ils s'arrêtent au périmètre du fournisseur, leur offre dynamique est étroite, et la racine de confiance appartient au fournisseur.

Les produits historiques de gestion des accès à privilèges. Forts sur les accès humains, l'enregistrement de session et la conformité. Plus lourds à exploiter, moins orientés machine et automatisation.

Les outils de chiffrement de fichiers versionnés. Légers, sans serveur, adaptés aux petites équipes. Sans trace de lecture, sans révocation, sans dynamique. Les limites de la section 1.8 s'appliquent intégralement.

Les secrets natifs des orchestrateurs. Disponibles sans rien installer, et limités à la plateforme, sans dynamique, avec les propriétés de stockage vues au chapitre 1.

OpenBao. Fork de Vault sous gouvernance de fondation, compatible avec le cœur, sans l'édition Enterprise. C'est l'option à considérer quand la licence est le critère bloquant.

Critère de synthèse : Vault se justifie quand la valeur de ses capacités différenciantes excède durablement le coût réel de l'exploiter sérieusement.

3.7 Quand Vault est disproportionné¶

Un cours de référence doit savoir déconseiller son sujet. Vault est disproportionné dans au moins trois situations. Une petite équipe, quelques dizaines de secrets statiques, un seul cloud, personne pour exploiter un service critique : le gestionnaire du cloud plus un coffre humain couvrent le besoin. Des secrets exclusivement manipulés par des humains : le gestionnaire de mots de passe est l'outil. Un unique cluster Kubernetes avec des secrets statiques et aucune exigence de PKI ni de dynamique : le rapport bénéfice sur coût d'exploitation ne se justifie pas.

Dans ces cas, installer Vault produit les coûts d'exploitation d'un service critique sans les bénéfices qui les paient.

Exemple : la décision d'Astrea¶

Astrea remplit les critères. Son environnement est hétérogène : serveurs sur site, migration Kubernetes en cours, CI en mode SaaS. Son cahier des charges issu du chapitre 2 exige des identités individuelles y compris pour les machines, des credentials de base rotatifs puis éphémères, une PKI interne pour le TLS de ses services, et un journal d'accès central. Sa direction a posé une contrainte de souveraineté qui exclut de placer la racine de confiance chez un fournisseur cloud, contrainte dont la portée se révélera en partie VII.

L'architecte fait signer un contrat d'attentes à sa direction, en trois points. Vault ne supprimera pas les secrets de l'organisation, il en changera la gestion. Il deviendra un service critique dont l'indisponibilité arrêtera les déploiements et les démarrages. Et son bénéfice dépendra d'un travail sur les consommateurs, pas seulement de l'installation du serveur.

Sécurité : Vault concentre le risque¶

Vault ne réduit pas le risque, il le concentre, et c'est la concentration bien gérée qui réduit le risque. Avant Vault, les secrets d'Astrea étaient indéfendables mais dispersés : compromettre l'un ne livrait pas les autres. Après Vault, ils sont défendables mais rassemblés : le serveur devient l'actif dont la compromission serait la plus grave et l'indisponibilité la plus paralysante.

Toute la suite du cours découle de cette phrase. Elle justifie une partie entière sur le modèle de sécurité et ses frontières (partie II), une sur le scellement (partie VII), une sur la haute disponibilité (partie VIII), une sur le durcissement et la réponse à incident (partie X), une sur la reprise (partie XI).

Corollaire d'exploitation : un Vault mal exploité est plus dangereux qu'une absence de Vault, parce qu'il ajoute un point de défaillance unique aux fuites qu'il n'a pas encore supprimées.

Erreurs fréquentes¶

Attendre de Vault les garanties d'un HSM. Les clés sont dans la mémoire d'un processus, avec les limites d'un logiciel (section 3.5, chapitre 5).

Déployer Vault comme un simple coffre. Y verser les secrets existants et brancher trois applications avec un token éternel donne les coûts d'exploitation de Vault et les bénéfices d'un fichier partagé.

Croire que l'adoption de l'outil vaut politique. Vault permet le moindre privilège, outille la rotation, produit l'audit. Il ne fait aucun des trois à votre place.

Choisir sur les fonctionnalités et ignorer l'exploitation. Le coût réel est celui du scellement, des sauvegardes, de la haute disponibilité et de l'astreinte.

Ignorer le changement de licence dans un dossier de décision. Il n'interdit pas l'usage interne, mais il appartient à l'analyse, au même titre que la disponibilité d'OpenBao (section 3.1).

Oublier la contrainte de souveraineté au moment du choix de scellement. Elle ne se découvre pas en partie VII : elle conditionne l'architecture dès le premier jour.

Mise en pratique : recommander un outillage¶

Sans machine. Pour chacun des trois contextes, choisissez l'outillage que vous recommanderiez, en justifiant par les sections 3.6 et 3.7 et par les principes du chapitre 2. Réponses commentées en fin de partie.

Une startup de six personnes, entièrement sur un unique fournisseur cloud, une vingtaine de secrets statiques, aucune personne dédiée à l'infrastructure.
Une entreprise industrielle multi-sites : applications sur site et dans deux clouds, exigence d'une PKI interne pour du TLS mutuel, volonté de credentials de bases éphémères, contrainte réglementaire de localisation des clés.
Une équipe plateforme opérant un unique cluster Kubernetes, avec des secrets statiques provenant du gestionnaire du cloud et aucune exigence de PKI.

Questions de compréhension¶

Que change concrètement le principe « API d'abord », pour un administrateur et pour un attaquant ?
Expliquez « tout est chemin » et sa conséquence sur le modèle d'autorisation.
Citez les trois comportements de sécurité par défaut et ce que chacun inverse.
Définissez en une phrase : mount, secrets engine, auth method, policy, token, lease, seal, barrière, audit device.
Pourquoi « Vault ne protège pas un secret après sa livraison » est-il capital ? Donnez les trois conséquences.
Dans quelles situations un gestionnaire de secrets du cloud est-il le meilleur choix, et dans lesquelles l'inverse ? Donnez le critère de synthèse.
Qu'implique « Vault ne réduit pas le risque, il le concentre » pour la suite du cursus ?
Citez trois situations où Vault est disproportionné, et l'outillage à recommander à la place.

Synthèse¶

Vault est un serveur d'API né en 2015, disponible en éditions Community, Enterprise et managée, dont la gouvernance récente appartient au dossier de décision : licence BSL depuis 2023 à partir de la version 1.15, fork OpenBao, acquisition par IBM finalisée début 2025. Trois principes le structurent : API d'abord, tout est chemin, sécurité par défaut. Ses cas d'usage vont du coffre central aux credentials dynamiques, au chiffrement comme service, à la PKI interne et à l'identité machine. Ses limites sont nettes : ce n'est ni un HSM, ni un coffre humain, ni un IAM, ni une solution de prévention de fuite, et il ne protège pas un secret livré. Enfin, il concentre le risque au lieu de le réduire, ce qui commande tout le reste du cursus.