Notifications
Clear all
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.
NHIMG editorial — based on content published by Infisical: A Guide to Terraform Secrets Management: Keeping Secrets Secure in Infrastructure as Code
Questions worth separating out
Q: Why do Terraform state files matter for secrets management?
A: State files matter because they can preserve sensitive values after the apply run ends.
Q: Why do data sources still create secrets risk in Terraform?
A: Data sources are read-only from Terraform's point of view, but the values they return are still written into state so future plans remain stable.
Q: What breaks when secrets are managed with sensitive=true alone?
A: Sensitive=true prevents accidental display in plans, outputs, and logs, but it does not encrypt state or stop Terraform from storing the underlying value.
Practitioner guidance
- Classify Terraform state as a secret-bearing asset Inventory every backend, local file, artifact store, and developer workstation that can read .tfstate.
- Replace stateful secret reads with ephemeral retrieval Use ephemeral resources for values that only need to exist during plan or apply, and reserve data sources for non-secret metadata and lookup paths.
- Remove standing CI credentials from Terraform pipelines Use short-lived OIDC-based identity for pipeline authentication so jobs do not depend on reusable client secrets or exported cloud keys.
What's in the full article
Infisical's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step Terraform examples for moving from hardcoded secrets to runtime secret retrieval.
- The exact behaviour of sensitive values, data sources, and ephemeral resources in state and plan files.
- Practical backend hardening guidance for remote state storage, locking, and encryption.
- Pipeline examples showing OIDC-based identity for Terraform and adjacent cloud access.
👉 Read Infisical's guide to Terraform secrets management and state file exposure →
Terraform state files and secrets: what IAM teams need to fix?
Explore further
12/07/2026 12:32 pm
State-file secrecy is an assumption failure, not a display issue: Terraform secrets exposure persists because the platform assumes persistence is acceptable for reconciliation data. That assumption breaks when the stored object contains credentials, because state becomes a high-value secret repository rather than a configuration ledger. The implication is that teams must classify state as an identity-bearing asset, not just a deployment artifact.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: Who is accountable when a managed Terraform platform exposes secrets or misapplies policy?
A: The vendor may operate the service, but the organisation remains accountable for policy intent, access boundaries, and exception handling. If the platform stores or executes secrets, teams still need ownership for approval rules, periodic review, and offboarding of access that is no longer needed.
👉 Read our full editorial: Terraform secrets management still leaves state file exposure
