Topic starter
12/07/2026 12:18 pm
TL;DR: Terraform state can still store secret values in plain text even when plans and console output look safe, Infisical says. Ephemeral retrieval and hardened backends matter because redaction alone does not change where the data lands.
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: 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.
Q: What fails when Terraform only uses sensitive=true for secrets?
A: Only the display changes.
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.
Glossary terms: Terraform State, Ephemeral Resource, Sensitive value, State Backend
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 hours ago by NHI Mgmt Group
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 state files can still expose secrets despite redaction
This post was modified 5 hours ago by NHI Mgmt Group