Terraform state security, remote backends, locking, encryption
Terraform state is a JSON file that maps your configuration to the real cloud resources it manages. It contains every resource ID, every computed attribute, and every sensitive value an apply produced, including database passwords, private keys, and initial admin credentials. Treat it as production data.
Why Terraform state security matters
State is not an artifact. It is live, mutable infrastructure metadata containing secrets. Putting it in an artifact registry, a shared file server, or a Git repo turns every read on that store into credential exfiltration. The fix is structural, not accidental: pick a remote backend with locking and encryption from day one.
Common mistakes with Terraform state security
- Committing `terraform.tfstate` to Git, even briefly.
- Using a remote backend without locking, concurrent applies corrupt state silently.
- Storing state in an artifact repository (JFrog, Nexus, ECR), these are for immutable build outputs, not live state.
- Not marking sensitive outputs with `sensitive = true`, so plan output leaks them in CI logs.
How attackers exploit Terraform state security
Stolen developer laptop → `terraform.tfstate` on disk → JSON contains the RDS master password generated at first apply → attacker connects directly to production database. The Terraform configuration was clean; the state file was not.