HashiCorp Vault : gérer les secrets

Dans les architectures Cloud modernes, la gestion des secrets représente un défi majeur pour les équipes DevOps et sécurité. Mots de passe de bases de données, clés API, certificats TLS, tokens d'authentification : ces informations sensibles se multiplient à mesure que les applications se complexifient. Comment les stocker de manière sécurisée ? Comment contrôler qui y accède ? Comment les faire tourner automatiquement sans interruption de service ? Ces questions ont donné naissance à une nouvelle catégorie d'outils : les gestionnaires de secrets.

Véritable coffre-fort numérique pour les infrastructures, HashiCorp Vault s'est imposé comme la référence du marché pour la gestion centralisée des secrets. Développé par HashiCorp, l'éditeur derrière Terraform et Consul, ce projet open source permet aux organisations de stocker, accéder et distribuer des secrets de manière sécurisée tout en maintenant une traçabilité complète des accès. Utilisé par des entreprises comme Adobe, Cisco ou encore Shopify, Vault est devenu un pilier des architectures zero-trust et des pratiques DevSecOps modernes.

Qu'est-ce que HashiCorp Vault ?

HashiCorp Vault est une plateforme de gestion des secrets et de protection des données sensibles. Contrairement à une simple base de données chiffrée, Vault propose une approche dynamique et centralisée où les secrets peuvent être générés à la demande, limités dans le temps et révoqués instantanément.

Le principe fondamental de Vault repose sur plusieurs concepts clés qui le distinguent des solutions traditionnelles de stockage de secrets :

• Chiffrement centralisé : toutes les données sont chiffrées avant d'être stockées, avec une gestion des clés de chiffrement intégrée.
• Secrets dynamiques : Vault peut générer des credentials à la volée pour des bases de données, des services Cloud ou des certificats, avec une durée de vie limitée.
• Contrôle d'accès granulaire : des politiques précises définissent qui peut accéder à quoi, avec une authentification multi-méthodes.
• Audit complet : chaque accès, chaque opération est journalisée pour une traçabilité totale.
• Révocation instantanée : en cas de compromission, les secrets peuvent être révoqués immédiatement, y compris tous les secrets dérivés.

Cette architecture répond à un problème récurrent dans les entreprises : la prolifération des secrets stockés dans des fichiers de configuration, des variables d'environnement ou des gestionnaires de mots de passe inadaptés. Avec Vault, les applications ne stockent plus les secrets eux-mêmes, mais uniquement les credentials pour accéder à Vault, qui devient la source unique de vérité pour toutes les informations sensibles.

L'outil s'intègre naturellement dans les workflows DevOps modernes. Les pipelines CI/CD peuvent récupérer dynamiquement les secrets nécessaires au déploiement, les applications conteneurisées obtiennent leurs configurations sensibles au démarrage, et les équipes d'exploitation disposent d'une vue centralisée sur l'ensemble des accès aux ressources critiques.

Fonctionnalités principales

Vault se distingue par la richesse de ses fonctionnalités, organisées autour de différents moteurs de secrets (secrets engines) qui répondent chacun à des cas d'usage spécifiques.

Secrets statiques clé-valeur

Le moteur KV (Key-Value) est le plus simple et le plus utilisé. Il permet de stocker des paires clé-valeur de manière sécurisée, comme des mots de passe, des clés API ou des tokens. La version 2 de ce moteur ajoute le versioning, permettant de conserver l'historique des modifications et de revenir à une version antérieure si nécessaire.

# Stockage d'un secret
vault kv put secret/mon-application/database password="super-secret-password"

# Récupération d'un secret
vault kv get secret/mon-application/database

# Accès à une version spécifique
vault kv get -version=2 secret/mon-application/database

Cette approche est idéale pour les secrets qui changent rarement et doivent être partagés entre plusieurs applications ou environnements.

Secrets dynamiques pour bases de données

L'une des fonctionnalités les plus puissantes de Vault réside dans sa capacité à générer des credentials à la demande pour des bases de données. Plutôt que de partager un mot de passe statique entre toutes les applications, chaque application obtient ses propres identifiants avec une durée de vie limitée.

Vault supporte de nombreuses bases de données : PostgreSQL, MySQL, MongoDB, Oracle, Microsoft SQL Server, et bien d'autres. Le principe est le suivant :

• Vault dispose d'un compte administrateur sur la base de données.
• Lorsqu'une application demande un accès, Vault crée un utilisateur temporaire avec les permissions définies.
• À l'expiration du lease (durée de vie), Vault supprime automatiquement l'utilisateur.

Cette approche réduit considérablement la surface d'attaque : même si des credentials sont compromis, ils expirent rapidement et leur révocation est automatique.

Gestion des certificats SSL/TLS

Le moteur PKI (Public Key Infrastructure) transforme Vault en une autorité de certification interne. Il permet de générer des certificats SSL/TLS à la demande pour sécuriser les communications entre services, sans dépendre d'une autorité externe pour les certificats internes.

Les avantages sont multiples :

• Automatisation complète : les certificats peuvent être générés et renouvelés automatiquement par les applications.
• Durée de vie courte : des certificats valides quelques heures ou quelques jours limitent l'impact d'une compromission.
• Élimination du processus manuel : plus besoin de gérer des demandes de certificats et leur distribution.

Cette fonctionnalité s'avère particulièrement utile dans les architectures microservices où le chiffrement mTLS (mutual TLS) entre services devient un standard de sécurité.

Gestion des clés SSH

Le moteur SSH permet de sécuriser l'accès aux serveurs de deux manières : soit en signant des clés publiques SSH avec un certificat de courte durée, soit en générant des credentials SSH one-time-password (OTP).

L'approche par signature de clés est particulièrement élégante : l'utilisateur soumet sa clé publique à Vault, qui la signe avec une durée de validité limitée. Les serveurs sont configurés pour faire confiance aux certificats signés par Vault, éliminant ainsi la nécessité de distribuer des clés publiques sur chaque serveur.

À lire : découvrez notre formation DevOps Engineer

Intégration avec Kubernetes

L'intégration de Vault avec Kubernetes représente un cas d'usage majeur, car elle permet aux applications conteneurisées d'accéder aux secrets de manière sécurisée et automatisée.

Authentification Kubernetes

Vault propose une méthode d'authentification native pour Kubernetes. Les Pods peuvent s'authentifier auprès de Vault en utilisant leur Service Account Token, un mécanisme natif de Kubernetes. Vault valide ce token auprès de l'API Kubernetes et accorde les permissions correspondantes selon les politiques définies.

Cette approche présente plusieurs avantages :

• Pas de secret à gérer côté application : le Service Account est automatiquement monté dans le Pod par Kubernetes.
• Granularité fine : les politiques Vault peuvent être liées à des namespaces, des Service Accounts ou des labels spécifiques.
• Rotation automatique : les tokens Kubernetes sont gérés par le cluster, sans intervention manuelle.

Vault Agent et Sidecar Injector

Pour simplifier l'intégration, Vault propose un Agent Injector qui fonctionne comme un webhook d'admission Kubernetes. Lorsqu'un Pod est annoté avec les bonnes annotations, l'Injector ajoute automatiquement un conteneur sidecar qui récupère les secrets depuis Vault et les rend disponibles à l'application.

apiVersion: v1
kind: Pod
metadata:
  annotations:
    vault.hashicorp.com/agent-inject: "true"
    vault.hashicorp.com/role: "mon-application"
    vault.hashicorp.com/agent-inject-secret-database: "secret/data/mon-application/database"
spec:
  serviceAccountName: mon-application
  containers:
    - name: app
      image: mon-application:latest

Avec cette configuration, les secrets sont automatiquement injectés dans le Pod sous forme de fichiers, sans que l'application n'ait besoin de connaître l'existence de Vault. Cette approche facilite la migration d'applications existantes vers une gestion centralisée des secrets.

Secrets Store CSI Driver

Une alternative plus récente consiste à utiliser le Secrets Store CSI Driver, qui monte les secrets Vault directement comme volumes Kubernetes. Cette approche est particulièrement adaptée aux applications qui s'attendent à trouver leurs configurations dans des fichiers, et permet également de synchroniser les secrets Vault avec des Secrets Kubernetes natifs.

Bonnes pratiques et considérations

L'adoption de Vault nécessite une réflexion sur l'architecture et les processus pour en tirer le meilleur parti.

Haute disponibilité : en production, Vault doit être déployé en cluster avec un backend de stockage distribué (Consul, PostgreSQL, ou le stockage intégré Raft). La perte de Vault signifie l'impossibilité pour les applications d'accéder à leurs secrets, ce qui en fait un composant critique de l'infrastructure.

Unsealing et auto-unseal : Vault démarre dans un état "sealed" (scellé) où les données sont inaccessibles. L'opération d'unsealing nécessite plusieurs clés détenues par différentes personnes (schéma de Shamir). Pour les environnements Cloud, l'auto-unseal via un service KMS (AWS KMS, Azure Key Vault, GCP Cloud KMS) simplifie les opérations tout en maintenant la sécurité.

Politiques et least privilege : la définition des politiques d'accès doit suivre le principe du moindre privilège. Chaque application, chaque équipe ne doit avoir accès qu'aux secrets strictement nécessaires. Les politiques Vault, écrites en HCL, permettent une granularité très fine sur les chemins et les opérations autorisées.

Audit et conformité : l'activation des audit logs est essentielle pour la traçabilité et la conformité réglementaire. Ces logs capturent chaque requête à Vault, permettant de répondre aux questions "qui a accédé à quoi et quand" lors d'audits ou d'investigations de sécurité.

À découvrir : notre formation DevOps Engineer

Conclusion

HashiCorp Vault s'est imposé comme la référence pour la gestion centralisée des secrets dans les infrastructures modernes. En combinant stockage sécurisé, génération dynamique de credentials et contrôle d'accès granulaire, il répond aux exigences de sécurité des architectures Cloud natives tout en s'intégrant naturellement dans les workflows DevOps.

Au-delà du simple stockage de mots de passe, Vault transforme la manière dont les organisations gèrent leurs informations sensibles. Les secrets dynamiques réduisent la surface d'attaque, l'audit complet facilite la conformité, et l'intégration native avec Kubernetes simplifie l'adoption dans les environnements conteneurisés. Pour les organisations engagées dans une démarche zero-trust ou DevSecOps, Vault représente un investissement stratégique qui centralise et sécurise un aspect critique de l'infrastructure, tout en offrant la flexibilité nécessaire pour s'adapter aux évolutions futures.