Pourquoi le state est-il sensible, et pourquoi sensitive = true ne suffit pas ?

Ce que le state contient vraiment

Après un apply, le state n’est pas une liste d’adresses. C’est une copie des attributs que le provider a lus ou écrits : mot de passe de base, secret d’un identifiant IAM access key, token d’un webhook, chaîne de connexion. HashiCorp le dit sans détour : traitez le state comme un secret.

sensitive = true sur une variable ou un output rédige la valeur dans le terminal, dans certaines UIs, dans les diffs de plan affichés. Ça n’empêche pas Terraform d’écrire la valeur dans le state. Un terraform state pull la rend. Un bucket S3 public ou un state commité dans Git la rend.

Ce qui tient, et ce qui est du théâtre

Tient :

• backend chiffré, bucket privé, accès par rôle, versioning ;
• jamais le state dans Git ;
• politiques : qui a le droit de state pull ;
• réduire les secrets gérés par Terraform (secret manager, valeurs éphémères / write-only quand le provider et la version le permettent).

Théâtre : mettre sensitive et croire le problème clos ; masquer un output tout en le passant à dix modules qui le recopient.

Les valeurs éphémères (Terraform récent) visent précisément à ne pas persister certains secrets dans le state. Les citer montre que vous suivez HashiCorp au-delà du blog de 2019. Elles ne dispensent pas de chiffrer le backend : tout le reste y reste.

Ce que l’intervieweur écoute

La phrase « sensitive, c’est de l’affichage, pas du stockage ». Si vous confondez les deux, la suite de l’entretien sécurité (CI, logs, artefacts de plan) part mal.

La relance probable

« Le plan sauvegardé est-il sensible ? »

Oui. Un fichier de plan binaire peut contenir des valeurs prévues. On le stocke comme un artefact privé, on ne le pose pas sur un job public.