📍 Article principal : Vault Associate. Ce tutoriel intègre Vault avec Terraform pour des workflows IaC sécurisés sans secrets dans le state.
L’intégration Vault + Terraform est la combinaison gagnante du DevSecOps moderne. Terraform provisionne l’infrastructure, Vault gère les secrets nécessaires à cette infrastructure (mots de passe RDS, API keys cloud, certificats TLS). Ensemble, ils permettent un workflow IaC complet où aucun secret n’apparaît dans le code Git ni dans le state Terraform. Ce tutoriel détaille le provider Vault officiel, les data sources pour lire les secrets dynamiquement, les patterns de bootstrap.
Provider Vault dans Terraform
HashiCorp maintient un provider Vault officiel pour Terraform qui expose toutes les ressources Vault en HCL. Configuration provider de base : spécifier l’adresse Vault et le mode d’authentification. Recommandation : ne jamais hardcoder les credentials dans le bloc provider — passer par variables d’environnement (VAULT_ADDR, VAULT_TOKEN) ou via OIDC depuis la CI.
Le provider permet deux usages distincts. Premier : gérer Vault lui-même via Terraform — créer auth methods, secrets engines, policies, mounts. Cette approche IaC pour Vault transforme la configuration en code versionné, reproductible, auditable. Deuxième : lire les secrets depuis Vault pour les utiliser dans d’autres ressources Terraform — par exemple récupérer un mot de passe RDS depuis Vault et l’injecter dans une ressource AWS.
Lire les secrets via data sources
Pour lire un secret KV stocké dans Vault, utiliser la data source vault_kv_secret_v2 : data "vault_kv_secret_v2" "db_password" { mount = "kv"; name = "production/database" }. Le secret peut ensuite être référencé dans n’importe quelle ressource : password = data.vault_kv_secret_v2.db_password.data["password"]. Le secret n’apparaît jamais en clair dans le code, et n’est pas stocké dans le state Terraform si on configure correctement (mark sensitive=true).
Pour les dynamic secrets, utiliser la data source correspondante. vault_database_secret_backend_static_role pour les credentials PostgreSQL, vault_aws_access_credentials pour AWS, etc. Chaque appel Terraform plan/apply génère un nouveau credential — pour les opérations courtes, c’est parfait. Pour les opérations longues, basculer sur Vault Agent qui gère le renewal et expose les secrets aux processus locaux.
Pattern de bootstrap : œuf et poule
Question classique : si Terraform a besoin de Vault pour ses secrets, et Vault a besoin d’être déployé pour fournir des secrets, comment résoudre cette dépendance circulaire ? Pattern recommandé : deux dépôts Terraform distincts. Dépôt 1 (bootstrap) déploie Vault lui-même avec credentials initiaux gérés en dehors de Vault — par exemple via cloud KMS pour l’auto-unseal et root token sealed dans un coffre. Dépôt 2 (workloads) utilise Vault pour ses secrets et déploie le reste de l’infrastructure.
Cette ségrégation prévient les boucles de dépendance et limite la surface d’attaque. Le dépôt bootstrap est rarement modifié (une fois Vault déployé), avec accès très restreint à quelques admins. Le dépôt workloads tourne fréquemment avec les pipelines normaux. Cette architecture est la pratique recommandée par HashiCorp pour les déploiements en production sérieux.
Authentication Terraform → Vault via OIDC
Pour l’authentification Terraform vers Vault depuis la CI, OIDC est le pattern moderne. GitLab et GitHub Actions exposent un JWT signé pour chaque job. Vault peut valider ce JWT via JWT auth method et délivrer un token Vault aux permissions adaptées. Plus aucun token Vault statique à gérer dans la CI — chaque job s’authentifie avec son identité unique.
Configuration côté Vault : activer JWT auth, configurer le provider OIDC pointant vers GitLab ou GitHub, créer un rôle qui mappe les claims JWT (project_id, ref, environment) aux policies. Configuration côté CI : ajouter id_tokens dans le job, faire appel à vault login avec le JWT, récupérer le token Vault, l’utiliser pour terraform plan/apply. Cette mécanique élégante élimine totalement les credentials statiques de la CI — sécurité maximale.
Cas concret : déploiement multi-cloud sécurisé
Pour ancrer dans un cas réel, voici un workflow type. La PME ouest-africaine déploie un service web sur Hostinger Cloud VPS avec base de données PostgreSQL. Vault stocke les credentials Hostinger API, les credentials PostgreSQL admin, les API keys Mobile Money. Terraform lit ces secrets via data sources Vault, provisionne le VPS via le provider Hostinger ou un compatible, configure la base, déploie l’application.
Aucun secret n’apparaît dans le code, le state Terraform reste propre (les valeurs sensibles sont marquées et n’apparaissent pas en clair), la rotation des credentials se fait dans Vault sans modifier Terraform. Pour les apprenants ouest-africains qui débutent, Hostinger propose un excellent rapport qualité-prix avec panneau en français pour pratiquer ce workflow. Au-delà de la pratique, cette architecture devient le standard de production pour les organisations sérieuses.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| Secrets dans le state Terraform | sensitive=true non appliqué | Marquer toutes les variables et outputs sensibles avec sensitive=true |
| VAULT_TOKEN dans Git | Tentation hardcoding | Toujours via VAULT_TOKEN env var ou OIDC depuis CI |
| Lease expiré pendant terraform apply | TTL trop court | Augmenter TTL des credentials utilisés par Terraform à 2-4h |
| Boucle dépendance Vault-Terraform | Single repo monolithique | Séparer bootstrap (Vault deployment) et workloads (apps) |
Adaptation au contexte ouest-africain
Pour les PME ouest-africaines, l’intégration Vault + Terraform constitue le standard de maturité DevSecOps. Cette compétence rend immédiatement éligible aux missions premium pour fintechs, banques, télécoms — secteurs où la sécurité des credentials est critique et où peu de profils maîtrisent réellement cette intégration. Pour les freelances, mettre en avant cette double compétence sur LinkedIn et Malt augmente significativement le taux de propositions reçues. Couplée aux certifications Terraform Associate et Vault Associate, c’est l’arsenal complet attendu par les recruteurs internationaux.
Pour aller plus loin
🔝 Retour à l’article principal : Vault Associate. Tutoriels précédents : HA, dynamic secrets, AppRole/JWT. Documentation provider Vault Terraform : registry.terraform.io/providers/hashicorp/vault.
L’intégration Vault + Terraform marque l’aboutissement du parcours DevSecOps moderne. Pour les apprenants ouest-africains qui maîtrisent les deux outils, le marché professionnel s’ouvre largement — missions internationales remote, postes Senior dans les grands groupes, conseil stratégique pour les transformations digitales. Cet investissement en certifications combinées (Terraform Associate + Vault Associate) constitue l’un des meilleurs ratios coût-bénéfice du marché tech francophone en 2026.