Vault Enterprise 2.0 remplace les credentials par les identités

Décembre 2015, HashiCorp publie la première version de Vault — le produit qui définit la gestion des secrets pour une génération d’ingénieurs infrastructure. Avril 2018, la version 1.0 ancre le produit comme la référence du marché. 28 janvier 2026, HashiCorp annonce Vault Enterprise 2.0 : la version qui enterre les credentials statiques. Le passage sous l’égide d’IBM après l’acquisition de 2024 n’a pas ralenti le produit — il a redéfini sa philosophie. Vault ne se demande plus « qui connaît le mot de passe » : il demande « qui peut prouver son identité ».

Le problème que dix ans de secrets n’ont pas résolu

Un secret, c’est une information qu’on partage entre deux parties pour établir une confiance. Depuis 2015, Vault stocke, chiffre, distribue et fait tourner ces secrets mieux que personne. Mais le modèle reste fondamentalement le même : une application détient un token ou un couple identifiant/mot de passe, et le présente pour s’authentifier.

Ce modèle a trois défauts structurels. D’abord, un secret statique qui fuit est un secret qui donne un accès permanent — le temps de détection et de rotation laisse une fenêtre d’exploitation. Ensuite, la prolifération des clouds et des clusters Kubernetes a explosé le nombre de endpoints à approvisionner : chaque service, chaque namespace, chaque région a besoin de ses propres credentials. Enfin, les identités machines ne sont pas gouvernées comme les identités humaines — pas de joiners/movers/leavers, pas de SSO, pas de révocation centralisée.

Vault Enterprise 2.0 ne corrige pas ces problèmes un par un. Il change la question.

Workload Identity Federation : plus de secrets statiques à synchroniser

La nouveauté la plus structurante de cette version est la Workload Identity Federation (WIF). Le principe est simple : au lieu de stocker une access key AWS ou un client secret Azure dans Vault pour synchroniser des secrets vers les clouds, Vault s’authentifie auprès d’AWS, Azure et GCP via des jetons OIDC éphémères.

Concrètement, le flux change de nature. Avant : Vault détient une IAM user access key longue durée, et l’utilise pour pousser des secrets vers AWS Secrets Manager. Si cette clé fuit, l’attaquant a un accès programmatique au compte AWS. Après : Vault échange un jeton d’identité signé contre des credentials temporaires STS, pousse les secrets, et le jeton expire. Aucun secret statique n’est jamais stocké pour l’opération de synchronisation.

Le même mécanisme s’applique à Azure (via Workload Identity Federation sur Entra ID) et à GCP (via Workload Identity Federation sur IAM). Pour les équipes qui gèrent des secrets multi-cloud — c’est-à-dire la quasi-totalité des entreprises au-delà de 200 employés — ce n’est pas un détail : c’est la suppression d’une classe entière de risques.

SPIFFE entre aussi dans la danse. Vault 2.0 supporte la délivrance de JWT-SVID, les certificats d’identité standardisés du projet SPIFFE, permettant à une charge de travail authentifiée par Vault de participer à un mesh d’identité inter-organisationnel sans traduction de format.

Rotation automatisée des comptes Linux : le casse-tête des machines virtuelles

Le deuxième pilier est le Local Accounts Secrets Engine, un moteur de secrets qui automatise la rotation des mots de passe des comptes locaux Linux.

Le problème qu’il résout est vieux comme SSH. Chaque machine Linux a un compte root et des comptes de service locaux dont les mots de passe sont partagés entre administrateurs, stockés dans des fichiers .env ou, pire, codés en dur dans des scripts de déploiement. Les faire tourner est une corvée que personne ne priorise — les audits de conformité le rappellent une fois par an, et entre-temps, rien ne bouge.

Le Local Accounts Secrets Engine se branche sur les machines Linux via SSH et prend en charge la rotation complète : génération d’un nouveau mot de passe, application sur la machine cible, stockage du nouveau secret dans Vault, révocation de l’ancien. L’opération est planifiable, la rotation est atomique côté Vault, et le Rotation Policy standardisé définit le comportement en cas d’échec — exponential backoff, gestion des orphelins, nouvelle tentative automatique.

Pour les opérateurs qui gèrent des flottes de machines virtuelles dans des vSphere, des clusters OpenStack ou du bare-metal, c’est la fin du tableur de mots de passe partagés.

Chiffrement d’enveloppe haute performance

Le troisième pilier, plus technique mais tout aussi structurant, est le High-Performance Envelope Encryption dans le moteur Transit.

Le principe du chiffrement d’enveloppe est connu : une Data Encryption Key (DEK) chiffre les données, une Key Encryption Key (KEK) chiffre la DEK. Vault joue le rôle du gardien des KEK — il ne voit jamais les données en clair, ce qui le rend utilisable pour du chiffrement in-place de volumes massifs sans en faire un goulot d’étranglement.

La version 2.0 muscle ce modèle pour les débits enterprise. Les cas d’usage visés sont le chiffrement de logs, de backups, de volumes de bases de données — des workloads où le volume de données rend le chiffrement naïf prohibitif. Vault ne déchiffre pas les données : il ne fait que déballer les DEK à la demande, et le chiffrement/déchiffrement effectif reste côté application.

AWS KMS multi-region keys complète le tableau : une même clé peut être répliquée sur plusieurs régions AWS, simplifiant les architectures de reprise après sinistre.

Zero Trust par l’identité, pas par le réseau

Ce qui relie ces trois piliers — WIF, rotation Linux, chiffrement d’enveloppe — c’est une refonte du modèle de confiance. Le Zero Trust ne se décrète pas : il se construit sur la capacité à vérifier l’identité de chaque acteur à chaque instant.

Vault 2.0 traduit ce principe en trois couches opérationnelles :

• Authentification par identité, pas par secret. Un pod Kubernetes ne présente pas un token stocké dans un Secret — il présente un jeton OIDC signé par le ServiceAccount du cluster, que Vault vérifie auprès du Kubernetes API.
• Autorisation granulaire et contextualisée. Le Visual Policy Generator dans l’interface graphique produit des politiques ACL à partir de cas d’usage concrets. Les templates d’identité permettent de dériver les droits d’accès à partir des attributs de l’entité — son namespace, son groupe, son rôle.
• Cycle de vie automatisé. Le SCIM 2.0 (beta) provisionne automatiquement les entités et les groupes Vault depuis les plateformes d’identité externes. Les Feature Introduction Pages guident les nouveaux utilisateurs dans la découverte des capacités du produit.

Le résultat est un système où aucun secret longue durée n’est requis pour établir la confiance. Les identités sont vérifiées à chaque requête, les autorisations sont dérivées des attributs, et les credentials résiduels sont automatiquement renouvelés.

Intégration Kubernetes : le laboratoire du Zero Trust

Kubernetes est le terrain naturel de ce modèle. Vault 2.0 renforce l’intégration sur trois fronts :

D’abord, le Secret Sync avec WIF permet de synchroniser les secrets Vault vers les Secrets Kubernetes natifs sans stocker de credentials cloud dans le cluster. Un Vault Agent sidecar injecte les secrets dans le pod sans passer par l’API Kubernetes — le secret n’existe que dans un volume tmpfs, en mémoire, et expire avec le pod.

Ensuite, l’authentification Kubernetes native est enrichie : Vault peut désormais vérifier les jetons SPIFFE émis par Cert-Manager ou Istio en plus des JWT de ServiceAccount, ce qui unifie l’identité de la charge de travail entre le mesh de service et le gestionnaire de secrets.

Enfin, le support natif des agents AI (introduit en beta dans la 2.0.3 de juin 2026) prépare le terrain pour les workloads d’IA générative qui doivent accéder à des secrets sans intervention humaine — un cas d’usage qui met à l’épreuve tous les modèles de sécurité traditionnels.

Verdict

Vault Enterprise 2.0 n’est pas une mise à jour incrémentale — c’est un changement de paradigme qui aligne la gestion des secrets sur les principes du Zero Trust. La question n’est plus de savoir si vous devez l’adopter, mais à quel rythme.

Si vous gérez des secrets multi-cloud avec des IAM keys statiques, la Workload Identity Federation est la migration prioritaire : elle supprime une classe de risque sans changer vos workflows applicatifs. Si vous administrez une flotte de machines Linux avec des comptes locaux partagés, le Local Accounts Secrets Engine remplace une corvée manuelle par une rotation automatisée et auditée. Si vous chiffrez des volumes de données importants, le chiffrement d’enveloppe de la version 2.0 tient la charge sans devenir un point de congestion.

La migration depuis Vault 1.x n’est pas transparente — la version 2.0 introduit des breaking changes documentés, notamment sur l’authentification Azure qui exige désormais une configuration explicite plutôt que de se rabattre sur les variables d’environnement. Mais le chemin est balisé, et le Support Cycle-2 d’IBM garantit au moins deux ans de support standard par version majeure.

Pour les équipes qui ont envisagé OpenBao, le fork communautaire né du changement de licence de 2023, la direction prise par Vault sous IBM sera scrutée de près. La version 2.0 donne un premier élément de réponse : le produit n’est pas en maintenance, il est en refondation.

Références

• HashiCorp Blog — Vault Enterprise 2.0 Modernizes Identity Security at Scale, janvier 2026.
• Vault 2.x Release Notes, HashiCorp Developer.
• Advancing Secret Sync with Workload Identity Federation, HashiCorp Blog.
• The Future of Secrets and Identity Management, HashiCorp Blog.
• InfoQ — HashiCorp Vault 2.0 Marks Shift to IBM Lifecycle with New Identity Federation, 24 avril 2026.
• Vault Enterprise — SCIM Identity Provisioning, HashiCorp Developer.
• Vault — Local Accounts Secrets Engine, HashiCorp Developer.
• Vault — Envelope Encryption, HashiCorp Developer.