HashiCorp Vault : Pilier de la Sécurité DevOps chez WizOps
Vault : Le Coffre-Fort de Mes Infrastructures
HashiCorp Vault est un outil que je déploie depuis des années, et qui est devenu indispensable dans ma stack. Chez WizOps, chaque infrastructure Kubernetes que je gère utilise Vault (ou un équivalent cloud-native) pour la gestion des secrets. Voici pourquoi, et comment je l'utilise concrètement.
Le Problème Que Vault Résout
Avant Vault, les secrets (mots de passe de base de données, clés API, certificats TLS) finissaient dans des endroits dangereux : variables d'environnement en clair, fichiers .env committés par erreur, secrets Kubernetes en base64 (qui n'est pas du chiffrement). Chez un client que j'ai audité, les credentials de la base de données de production étaient dans un fichier docker-compose.yml sur un dépôt Git accessible à toute l'équipe, y compris les stagiaires.
Vault centralise tous les secrets dans un coffre-fort chiffré, avec un contrôle d'accès fin et un audit trail complet.
Mon Setup Vault en Kubernetes
Sur mes projets, je déploie Vault via le Helm chart officiel HashiCorp en mode haute disponibilité (3 réplicas avec backend Raft). L'intégration avec Kubernetes se fait via le Vault Agent Injector ou l'External Secrets Operator, selon le contexte.
Chez un client dans l'édition logicielle, le setup complet :
- Vault en HA sur 3 pods avec storage Raft
- Authentification Kubernetes (les pods s'authentifient automatiquement via leur ServiceAccount)
- Politiques granulaires : chaque namespace a accès uniquement à ses propres secrets
- External Secrets Operator qui synchronise les secrets Vault vers des Kubernetes Secrets
- Rotation automatique des credentials de base de données via le database secrets engine
Le résultat : aucun secret en dur nulle part, rotation automatique, et un audit trail qui montre qui a accédé à quel secret et quand.
Vault vs Les Solutions Cloud-Natives
AWS Secrets Manager, Azure Key Vault, GCP Secret Manager : chaque provider a son propre service de gestion de secrets. Je les utilise aussi, notamment quand le client est mono-cloud et veut simplifier la stack.
Mais Vault a un avantage unique : il est cloud-agnostic. Chez un client qui a migré de GCP vers AWS, les secrets sont restés dans Vault sans aucune modification. Essayez de faire ça avec GCP Secret Manager.
Sur un projet dans le secteur de la Défense, nous utilisions le service OKMS d'OVH (le KMS souverain) couplé avec des External Secrets dans Kubernetes, une approche similaire à Vault mais intégrée à l'écosystème OVH.
La Conformité Facilitée
Pour les clients soumis à des normes (ISO 27001, HDS, SOC 2), Vault est un argument massif. L'audit trail natif, la rotation automatique des secrets, le chiffrement au repos et en transit, et les politiques d'accès granulaires cochent la plupart des exigences de conformité.
Chez un client en cours de certification ISO 27001, la présence de Vault dans l'architecture a considérablement simplifié l'audit sur le volet gestion des secrets.
Le Conseil Pratique
Si vous débutez avec Vault, ne déployez pas tout d'un coup. Commencez par le KV secrets engine pour centraliser vos secrets existants. Ajoutez ensuite l'authentification Kubernetes. Et enfin, quand vous serez à l'aise, activez les secrets engines dynamiques (database, AWS, PKI) pour la rotation automatique.
Vault est un investissement en complexité initiale qui rapporte sur le long terme. Et chez WizOps, c'est un pilier de chaque infrastructure que nous gérons.