Lire des secrets Vault depuis Terraform sans les figer dans le state

L'examen Terraform Professional cite nommément Vault au sous-objectif 2f. Le problème n'est pas de lire un secret Vault : c'est de le lire sans qu'il finisse en clair dans le state. Car la façon la plus répandue de le faire, une data source, recopie la valeur dans terraform.tfstate, et sensitive_values la marque true sans rien cacher du tout.

Ce guide montre le piège, puis la bonne combinaison : une lecture éphémère et une écriture write-only, pour qu'un secret externe transite de Vault jusqu'à son destinataire sans laisser de trace côté Terraform. Tous les exemples ont été exécutés sur Terraform v1.15.4 avec le provider hashicorp/vault en 5.x, contre un serveur vault server -dev.

Ce que vous allez apprendre

• Le piège : pourquoi la data source vault_kv_secret_v2 fait fuiter le secret
• La lecture éphémère : le bloc ephemeral "vault_kv_secret_v2"
• L'écriture write-only : data_json_wo et son argument de version
• Le duo éphémère + write-only, de bout en bout sans trace
• La rotation : piloter le renvoi par un entier de version

Prérequis

• Terraform 1.11 ou plus récent (installer Terraform) : les ressources éphémères et les arguments write-only l'exigent.
• Un serveur Vault : vault server -dev suffit, en mémoire, descellé, avec un jeton racine. Vault Community Edition est libre et gratuit.
• Les valeurs éphémères et les arguments write-only (valeurs éphémères, write-only).

Le piège : la data source recopie le secret en clair

La voie historique pour lire un secret KV v2 est une data source :

data "vault_kv_secret_v2" "source" {
  mount = "kvv2"
  name  = "app/db"
}

Elle fonctionne, mais elle recopie la valeur dans le state. Le provider émet d'ailleurs un avertissement de dépréciation sur cette data source.

sensitive_values ne cache rien

Le secret lu par cette data source est marqué sensitive dans le plan, mais reste en clair dans terraform.tfstate et dans terraform show -json. sensitive masque l'affichage humain, pas le contenu du state. Un secret Vault lu ainsi fuit exactement comme un secret codé en dur.

La lecture éphémère : ephemeral "vault_kv_secret_v2"

Le provider hashicorp/vault en 5.x expose la même lecture sous forme éphémère. Un bloc ephemeral produit une valeur disponible pendant l'opération, mais jamais écrite dans le state ni le plan :

ephemeral "vault_kv_secret_v2" "source" {
  mount = "kvv2"
  name  = "app/db"
}

On référence son résultat par ephemeral.vault_kv_secret_v2.source.data["password"]. Cette valeur ne peut aller que dans un contexte éphémère : une configuration de provider, un provisioner, ou un argument write-only. C'est ce dernier qui complète la chaîne.

L'écriture write-only : data_json_wo

La ressource vault_kv_secret_v2 a deux façons d'écrire son contenu :

Argument	Persisté dans le state ?
data_json (ordinaire)	oui (marqué sensible, mais présent)
data_json_wo (write-only)	non, jamais

Glissez pour voir

L'argument write-only forme un couple obligatoire avec un numéro de version :

resource "vault_kv_secret_v2" "cible" {
  mount = "kvv2"
  name  = "app/copie"

  data_json_wo         = jsonencode({ password = ephemeral.vault_kv_secret_v2.source.data["password"] })
  data_json_wo_version = 1
}

Après l'apply, dans terraform show -json : data_json_wo vaut null, data_json vaut null, data est un objet vide ; seul data_json_wo_version subsiste, avec un nombre bien réel.

Le duo éphémère + write-only

Bout à bout, le secret ne touche jamais le disque côté Terraform : lu par un ephemeral (pas de state), écrit par un data_json_wo (pas de state). Il transite en mémoire pendant l'opération, du KV source vers le KV cible. C'est la réponse complète au sous-objectif 2f, et la seule qui ne laisse aucune trace, ni en clair ni sous forme dérivée.

La rotation : piloter le renvoi par la version

Comme tout write-only, data_json_wo n'est renvoyé au provider que lorsque son numéro de version change. Conséquence directe, vérifiée à l'exécution :

• changer le secret dans le KV source sans toucher data_json_wo_version ne produit aucun plan : Terraform ne suit pas ce qu'il ne stocke pas ;
• porter la version de 1 à 2 produit un plan, et l'apply pousse la nouvelle valeur dans la cible, dont la métadonnée KV passe à la version 2.

C'est le mécanisme de rotation : on incrémente un entier, jamais on ne manipule le secret en clair dans la configuration.

À retenir

• La data source vault_kv_secret_v2 fuit le secret dans le state (et est dépréciée) ; sensitive n'y change rien.
• Le bloc ephemeral "vault_kv_secret_v2" lit sans persister ; sa valeur ne va que dans un contexte éphémère.
• data_json_wo écrit sans persister ; data_json_wo, data_json valent null et data est vide dans le state.
• Seul data_json_wo_version subsiste et pilote la rotation : sans son incrément, un nouveau secret source est ignoré.
• Le duo éphémère + write-only ne laisse aucune trace côté Terraform.

FAQ : questions fréquentes

Les questions ci-dessous portent sur les points qui bloquent le plus souvent : la data source qui fuit, la façon de lire sans persister, et pourquoi un secret changé côté Vault n'est pas repris. Chaque réponse donne la vérification correspondante.

Pourquoi ne pas lire un secret Vault avec la data source vault_kv_secret_v2 ?

Parce qu'elle recopie la valeur en clair dans le state, et sensitive_values la marque true sans rien cacher. Le provider émet en plus un avertissement de dépréciation. Un secret lu ainsi fuit comme un secret codé en dur : préférez la lecture éphémère.

Comment lire un secret Vault sans le persister dans le state ?

Avec un bloc ephemeral vault_kv_secret_v2, apporté par le provider vault 5.x. Un bloc ephemeral produit une valeur disponible pendant l'opération mais jamais écrite dans le state ni le plan. Sa valeur ne peut aller que dans un contexte éphémère, dont les arguments write-only.

Comment référencer la valeur d'un secret éphémère ?

Par ephemeral.vault_kv_secret_v2.NOM.data suivi de la clé entre crochets, par exemple ephemeral.vault_kv_secret_v2.source.data password. La map data porte les clés du secret KV. Cette référence ne peut alimenter qu'un contexte éphémère, sinon Terraform lève une erreur.

Quelle différence entre data_json et data_json_wo ?

data_json est l'argument ordinaire : il persiste la valeur dans le state, marquée sensible mais présente. data_json_wo est sa variante write-only : la valeur est envoyée au provider mais jamais écrite dans le state. data_json_wo forme un couple obligatoire avec data_json_wo_version.

Pourquoi mon secret changé côté Vault n'est-il pas repris par Terraform ?

Parce que data_json_wo n'est renvoyé au provider que lorsque data_json_wo_version change. Tant que la version reste identique, un plan ne propose rien, même si le secret source a changé dans Vault. Terraform ne suit pas ce qu'il ne stocke pas : incrémentez la version pour forcer le renvoi.

Le secret apparaît-il dans terraform show -json ?

Non, si vous lisez par un bloc ephemeral et écrivez par data_json_wo. L'éphémère ne produit aucune entrée dans le state, et l'argument write-only y laisse un null. La valeur du secret n'apparaît alors nulle part dans show -json ni dans le fichier terraform.tfstate.

Faut-il un vrai compte Vault pour tester ce guide ?

Non. vault server -dev démarre un serveur en mémoire, descellé, sur 127.0.0.1:8200, avec un jeton racine choisi. Vault Community Edition est libre et gratuit, sans licence ni inscription. C'est suffisant pour monter un moteur KV v2 et déposer un secret source.

Pour aller plus loin

• Les valeurs ephemeres : sortir un secret du state, sans le laisser fuir.
• Les arguments write-only : transmettre un secret au provider sans jamais le persister.
• Les donnees sensibles : sensitive : ce que sensitive masque, et ce qu'il ne masque pas.
• Les providers Terraform : configurer le provider Vault, source et version.
• Ephemeral resources : la reference officielle : le mecanisme sur lequel repose la lecture d'un secret.

×

📖 Voir la documentation →