sensitive : masquer les valeurs dans Terraform

sensitive = true empêche Terraform d’afficher une valeur dans le terminal, mais ne la retire pas du state. Si vous manipulez des mots de passe, tokens ou clés API, ce mécanisme est le premier réflexe à connaître. Il masque les valeurs dans terraform plan et terraform apply, et propage automatiquement le marquage à toute expression qui les référence. Par contre, le fichier state continue de contenir la valeur en clair : c’est la limite fondamentale que les ressources éphémères et les arguments write-only viennent résoudre.

Ce que vous allez apprendre

• Déclarer une variable sensitive : masquer les mots de passe dans le CLI
• Déclarer un output sensitive : empêcher l’affichage par terraform output
• Comprendre la propagation : toute expression dérivée est contaminée
• Connaître la limite : le state contient toujours la valeur en clair

Prérequis

• Variables Terraform comprises (variables Terraform)
• Outputs Terraform compris (outputs Terraform)

L’idée derrière sensitive

Pensez à un formulaire web avec un champ mot de passe :

# Affichage masqué
password_field = "••••••••"   # l'utilisateur voit des points
actual_value   = "S3cr3t!"    # la valeur est toujours en mémoire

# C'est exactement ce que fait sensitive = true :
# Terraform affiche (sensitive value) au lieu du contenu
# mais la valeur est toujours stockée dans le state

sensitive = true c’est le masquage visuel, pas le chiffrement. Comme un champ mot de passe HTML : les points remplacent les caractères à l’écran, mais la vraie valeur circule quand même dans le formulaire.

Analogie

En Excel, c’est comme formater une cellule en ;;; (triple point-virgule) pour cacher son contenu à l’affichage. La valeur reste dans la cellule et dans le fichier. sensitive fait pareil : masquage visuel, pas suppression.

Le problème : des secrets visibles partout

Sans précaution, Terraform affiche les valeurs de toutes les variables et de tous les outputs directement dans le terminal. Un mot de passe passé en variable se retrouve dans la sortie du plan, de l’apply, et dans les logs CI/CD.

variable "db_password" {
  description = "Mot de passe de la base de données"
  type        = string
}

Terraform will perform the following actions:
  + resource "aws_db_instance" "main" {
      + password = "S3cr3t!P@ssw0rd"
    }

Le mot de passe apparaît en clair dans le terminal. Dans un pipeline CI/CD, il finit dans les logs.

Déclarer une variable sensitive

Ajoutez sensitive = true dans le bloc variable :

variable "db_password" {
  description = "Mot de passe de la base de données"
  type        = string
  sensitive   = true
  default     = "S3cr3t!P@ssw0rd"
}

Terraform remplace la valeur par (sensitive value) dans toute sortie CLI :

Changes to Outputs:
  + db_password_raw = (sensitive value)

La valeur par défaut dans le code

L’exemple utilise default pour tester facilement. En production, ne mettez jamais un secret en dur dans le code. Passez la valeur via TF_VAR_db_password, un fichier .tfvars ignoré par Git, ou un système de secrets (Vault, Secrets Manager).

Déclarer un output sensitive

Un output qui expose une valeur sensible doit lui aussi être marqué sensitive = true :

output "db_password" {
  description = "Mot de passe de la base de données"
  value       = var.db_password
  sensitive   = true
}

Résultat de terraform output :

db_password = <sensitive>
db_username = "admin"

terraform output -json contourne le masquage

La commande terraform output -json affiche toutes les valeurs en clair, y compris celles marquées sensitive. Ce comportement est voulu par Terraform pour permettre l’intégration avec d’autres outils, mais il signifie que sensitive n’est pas un mécanisme de sécurité complet.

{
  "db_password": {
    "sensitive": true,
    "type": "string",
    "value": "S3cr3t!P@ssw0rd"
  }
}

La propagation automatique

Quand une expression fait référence à une variable marquée sensitive, le résultat de cette expression devient lui aussi sensitive automatiquement. Terraform vous oblige alors à marquer l’output correspondant, sinon il refuse le plan.

locals {
  connection_string = "${var.db_username}:${var.db_password}@db.example.com:5432"
}

output "connection_string" {
  description = "Chaîne de connexion complète"
  value       = local.connection_string
  sensitive   = true
}

Ici, connection_string contient var.db_password qui est sensitive. Si vous oubliez sensitive = true sur l’output, Terraform affiche une erreur claire :

│ Error: Output refers to sensitive values
│   on outputs.tf line 1:
│   1: output "connection_string" {
│ To silence this warning, add sensitive = true

La limite critique : le state contient tout

sensitive = true masque l’affichage CLI, mais ne protège pas le state.

Après un terraform apply, le fichier terraform.tfstate contient la valeur en clair :

terraform show -json | python3 -c "
import sys, json
d = json.load(sys.stdin)
for k, v in d['values']['outputs'].items():
    print(f'{k}: {v[\"value\"]}')
"

connection_string: admin:S3cr3t!P@ssw0rd@db.example.com:5432
db_password_raw: S3cr3t!P@ssw0rd
db_username: admin

Le mot de passe est lisible par quiconque a accès au state. Cela vaut pour un state local (fichier sur disque) comme pour un state distant (S3, HCP Terraform).

sensitive ne remplace pas le chiffrement du state

Pour protéger un state distant, utilisez le chiffrement côté serveur (SSE-S3, SSE-KMS) et restreignez les accès IAM. Mais même chiffré, le state est déchiffré à chaque plan ou apply. La vraie solution pour ne jamais stocker un secret dans le state est d’utiliser les ressources éphémères et les arguments write-only.

Anatomie

Mécanisme	Ce qu’il fait	Ce qu’il ne fait pas
sensitive = true (variable)	Masque dans plan, apply, output	Ne retire pas du state
sensitive = true (output)	Masque dans terraform output	output -json affiche en clair
Propagation	Contamine les expressions dérivées	Ne remonte pas vers les blocs parents

Glissez pour voir

Bonnes pratiques

1. Marquer systématiquement les secrets

Tout mot de passe, token ou clé doit avoir sensitive = true. C’est la première ligne de défense, même si elle est incomplète.

2. Ne jamais commiter de valeurs sensibles

Les fichiers .tfvars contenant des secrets doivent être dans .gitignore. Préférez TF_VAR_* en CI/CD ou un gestionnaire de secrets.

3. Protéger le state

Si vous utilisez un backend distant (S3, GCS, HCP Terraform), activez le chiffrement et limitez les accès. Le state est le maillon faible.

4. Connaître les alternatives modernes

sensitive = true reste indispensable pour l’affichage, mais depuis Terraform 1.11, les ressources éphémères et les arguments write-only permettent de ne jamais stocker un secret dans le state.

Dépannage

Symptôme	Cause probable	Solution
Output refers to sensitive values	Un output référence une valeur sensitive sans sensitive = true	Ajouter sensitive = true sur l’output
Une valeur apparaît en clair dans les logs CI	La variable n’est pas marquée sensitive	Ajouter sensitive = true
terraform output -json affiche le secret	Comportement normal de Terraform	Restreindre l’accès au state et aux commandes Terraform
Le secret est dans terraform.tfstate	sensitive ne protège pas le state	Chiffrer le backend distant ou passer aux ressources éphémères

Glissez pour voir

À retenir

1. sensitive = true masque une valeur dans toute la sortie CLI de Terraform.
2. La propagation est automatique : toute expression qui référence une valeur sensitive est contaminée.
3. terraform output -json affiche les valeurs en clair malgré le marquage.
4. Le state contient toujours la valeur : sensitive n’est pas un mécanisme de chiffrement.
5. Pour exclure un secret du state, utilisez les ressources éphémères et les arguments write-only (Terraform ≥ 1.11).

Prochaines étapes

Ressources éphémères Terraform Créer des valeurs temporaires qui ne sont jamais stockées dans le state ou le plan.

Arguments write-only Passer des secrets aux providers sans que Terraform ne les persiste.

Variables Terraform Revoir les bases des variables si les notions de type et validation ne sont pas encore claires.

×

📖 Voir la documentation →