TP 32 : Gérer les données sensibles et éphémères

TP 32 : Gérer les données sensibles et éphémères

Objectifs

À l’issue de ce TP, vous serez capable de :

• constater qu’une valeur sensitive est masquée à l’affichage mais stockée en clair dans le state ;
• déclarer des variables et outputs sensitive ;
• utiliser des variables et ressources éphémères qui ne sont pas persistées ;
• utiliser un argument write-only (*_wo) pour ne rien laisser dans le state ni le plan.

Prérequis

• Terraform >= 1.10 pour les valeurs éphémères (variables, outputs, ressources éphémères).
• Terraform >= 1.11 pour les arguments write-only (*_wo) sur les ressources gérées.
• Le provider random suffit pour l’essentiel.

Contexte

InfraBank a découvert des mots de passe en clair dans un state stocké en S3. sensitive masque l’affichage mais ne protège pas le state. Les valeurs éphémères, elles, ne laissent aucune trace.

Étape 1 : sensitive masque, mais ne chiffre pas

versions.tf

terraform {
  required_version = ">= 1.11"
  required_providers {
    random = {
      source  = "hashicorp/random"
      version = "~> 3.6"
    }
  }
}

main.tf

variable "db_password" {
  type      = string
  sensitive = true
  default   = "SuperSecret-1234"
}

resource "random_password" "generated" {
  length  = 24
  special = true
}

output "generated_password" {
  value     = random_password.generated.result
  sensitive = true
}

terraform init
terraform apply -auto-approve
terraform output generated_password
# (sensitive value)  -> masqué à l'affichage

Maintenant, regardez le state :

terraform state show random_password.generated | grep result
# result = "..."   -> la valeur est bien là, EN CLAIR
grep -o 'SuperSecret-1234' terraform.tfstate && echo ">>> mot de passe présent dans le state"

Conclusion : sensitive masque les logs et l’affichage, mais le state contient la valeur en clair. C’est pourquoi le state doit être traité comme une donnée sensible (chiffrement au repos, accès restreint — voir TP 22 et TP 33).

Étape 2 : Variables éphémères

Une variable ephemeral n’est jamais écrite dans le state ni dans le plan. Elle est recalculée à chaque exécution et ne peut être utilisée que dans des contextes eux aussi éphémères (configuration de provider, autre valeur éphémère, argument write-only).

variable "session_token" {
  type      = string
  sensitive = true
  ephemeral = true
}

Une variable éphémère peut avoir une valeur par défaut, mais sa valeur ne « fuit » jamais vers un artefact.

Étape 3 : Ressources éphémères

Une ressource éphémère (bloc ephemeral) lit ou ouvre quelque chose de temporaire (un secret, une connexion) sans rien persister. Elle est exécutée à chaque plan et chaque apply.

# Génère un mot de passe qui n'atterrit jamais dans le state
ephemeral "random_password" "db" {
  length  = 24
  special = true
}

À la différence de random_password en ressource gérée (étape 1), aucune valeur de ephemeral.random_password.db n’est stockée. En contrepartie, la valeur peut différer entre plan et apply si elle est non déterministe : les valeurs éphémères ne sont pas figées d’un stade à l’autre.

Les outputs éphémères sont autorisés uniquement hors module racine (pour passer une valeur à un autre module), jamais à la racine — sinon ils seraient écrits dans le state.

Étape 4 : Arguments write-only

Un argument write-only (*_wo) accepte une valeur éphémère et ne la persiste ni dans le plan ni dans le state. Le provider doit le supporter. Le motif type : générer un secret en ressource éphémère, puis l’injecter dans un argument write-only, en pilotant les changements par un argument de version (*_wo_version).

# Exemple de motif (provider AWS, aws_db_instance)
ephemeral "random_password" "db" {
  length           = 20
  override_special = "!#$%&*()-_=+[]{}<>:?"
}

resource "aws_db_instance" "example" {
  engine            = "postgres"
  instance_class    = "db.t3.micro"
  allocated_storage = 5
  username          = "infrabank"

  password_wo         = ephemeral.random_password.db.result
  password_wo_version = 1   # incrémenter pour renouveler le secret
}

Points clés :

• password_wo n’apparaît ni dans le plan ni dans le state.
• Comme Terraform ne stocke pas la valeur, il ne peut pas détecter son changement : c’est password_wo_version qui signale « le secret a changé, envoie la nouvelle valeur au provider ».
• Résultat : un mot de passe de base de données géré par Terraform, sans jamais figurer dans le state.

Étape 5 : Vérifier l’absence de trace

Pour un secret passé par une variable/ressource éphémère ou un argument write-only :

terraform apply -auto-approve
# Cherchez la valeur du secret dans le state : elle ne doit pas y être
grep -c "le-secret-attendu" terraform.tfstate || echo "absent du state, comme attendu"

Vérification

• Une valeur sensitive classique est retrouvée en clair dans terraform.tfstate.
• Une valeur passée par ressource éphémère / argument write-only est absente du state et du plan.
• Les outputs éphémères sont refusés à la racine.

Nettoyage

terraform destroy -auto-approve