Lion Cipher Lab
Secure your Terraform state
- Cloud Security
- Intermediate
- ~40 min
- Free · no account required
Why it matters
The number-one Terraform security mistake is treating the state file as if it were harmless plumbing. It is not. terraform.tfstate is a plaintext JSON record of everything Terraform manages, and when a resource has a secret -- a database password, a private key, a generated token -- Terraform writes that secret into state VERBATIM so it can manage the resource next time. People discover this the hard way: a `random_password` or an RDS password ends up committed to a Git repo inside the state file, and now the secret is in history forever. The trap that makes it worse is the `sensitive = true`…
What you'll learn
- seeing that Terraform state (terraform.tfstate) is plaintext JSON by design, and reading a secret straight out of it
- understanding that `sensitive = true` only hides values from CLI output -- it does NOT encrypt or redact them in the state file
- treating the state file as a secret: gitignore it, never commit it, control who can read it
- what a remote backend adds -- encryption at rest and state locking -- and how S3+DynamoDB, GCS, and Terraform Cloud provide each
- the judgment call: when local state is acceptable (solo throwaway lab) vs when you MUST have remote encrypted+locked state (any team, any real secret)
- the pro habit: keep secrets in a secrets manager referenced at apply time instead of baking them into state
Steps in this lab
- The mistake we're going to make on purpose
- Set up a scratch folder (assumes Terraform is installed)
- Write a config that puts a secret into state
- Init and apply -- watch sensitive hide the value
- Open the state file and read the secret anyway
- Fix #1 -- treat state as a secret: never commit it
- Fix #2 -- the remote backend: encryption at rest + state locking
- The way a pro does it differently -- and when NOT to bother