Topic starter
12/07/2026 12:18 pm
TL;DR: Terraform can keep secrets out of code, but ordinary data sources still write fetched values into state files, while sensitive=true only hides them from display, according to Infisical. Ephemeral resources, short-lived identity, and hardened backends become the real control stack when infrastructure as code handles credentials.
Editorial analysis by NHI Mgmt Group, based on content published by Infisical: “A Guide to Terraform Secrets Management: Keeping Secrets Secure in Infrastructure as Code”.
Key questions
Q: What fails when Terraform only uses sensitive=true for secrets?
A: Only the display changes.
Q: When should teams prioritise ephemeral secret handling over data sources in Terraform?
A: Prioritise ephemeral handling when the value is only needed during the run and should not persist after apply.
Q: What are the signs that Terraform secret handling is failing in practice?
A: Common warning signs include secrets appearing in version control, configuration files, logs, or Terraform outputs, along with teams sharing credentials across environments.
Practitioner guidance
- Use ephemeral resources for run-time-only secrets Reserve Terraform data sources for values that can safely persist in state, and move passwords or tokens that only need to exist during a run into ephemeral flows.
- Remove secret values from code and variables Store real secret values in a dedicated secrets manager and pass references or environment bindings into Terraform instead of hardcoding values in .tf or .tfvars files.
- Harden the state backend as a sensitive store Encrypt the backend, enable versioning and locking, and restrict read access to the identities that actually run Terraform, because state may still contain readable secret material.
Bottom line: Terraform state can hold secret values in plain text even when the plan and console output look safe.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
12/07/2026 12:32 pm
State file exposure is a lifecycle failure, not a display problem: Terraform’s sensitive flag solves visibility on screen, but it does not solve where the secret lives after the run. The article shows that a secret can be hidden in the plan and still be plain text in state, which means the governance failure sits at storage and lifecycle boundaries. Practitioners should stop treating redaction as protection and start treating state as a governed credential repository.
A few things that frame the scale:
- Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
A question worth separating out:
Q: How should teams govern Terraform credentials and state access together?
A: Govern them as one identity path. The credentials Terraform uses to reach cloud APIs or a secrets platform should be short-lived, while the state backend should be encrypted, versioned, locked, and readable only by the automation identity that needs it. That keeps execution access and storage access from collapsing into the same blast radius.
👉 Read our full editorial: Terraform secrets management still leaves state file exposure