7 Terraform State Security Controls Worth Enforcing
Terraform state security fails at one predictable point: the state file itself. Terraform stores the values of every sensitive variable in plaintext inside its state and plan files, so anyone who can read those files can read every secret — database passwords, private keys, API tokens — even when the configuration marks them as sensitive. That is why securing state takes layered controls rather than a single switch: values that never enter state at all, an encrypted remote backend with strict access control, keyless authentication for the pipeline, and audit trails on every read. These are the seven controls worth enforcing, in the order you should implement them.
Why state files leak secrets
HashiCorp’s documentation is unusually direct about the limits of the sensitive argument: it redacts values from the Terraform CLI and the HCP Terraform UI, but it encrypts nothing. The value sits in the state file and in every saved plan file in readable form, and terraform output -raw prints it back in plain text on demand. Local development makes the exposure worse: with no remote backend configured, Terraform writes the entire state as a plaintext file on the engineer’s machine, and that file regularly ends up committed to a repository or attached to a CI log.
The practical consequence is simple: state access is credential access. Treat the state bucket, the lock table and the CI role that reads them as production secrets infrastructure, not as plumbing that ships with defaults.
Ephemeral values and write-only arguments
The most effective recent change to this threat model is keeping secrets out of state in the first place. Terraform 1.10 added ephemeral values, and Terraform 1.11 added write-only arguments, and both keep secret values out of state and plan files entirely. An ephemeral variable exists only for the duration of a single operation. A write-only argument such as password_wo hands a generated password to the provider, the provider applies it to the resource, and Terraform discards the value instead of persisting it to disk. Providers increasingly ship write-only variants for exactly this reason.
| Control | What it actually does | What it does not do |
|---|---|---|
sensitive = true | Redacts values in CLI output and the HCP Terraform UI | Does not encrypt; the value stays readable in state and plan files |
ephemeral variables and resources | Omits values from state and plan files; exists only during a run | Needs Terraform 1.10 or later plus provider support |
Write-only arguments ending in _wo | Sends a value to the provider without storing it | Needs Terraform 1.11 or later; updates handled through _wo_version |
| Remote backend with encryption | Keeps state off engineer machines; encrypts at rest and in transit | Does not fix an over-broad bucket policy |
| OIDC pipeline authentication | Replaces static cloud keys with short-lived tokens | Needs tight attribute conditions to constrain trust |
Migrating a database password to an ephemeral resource plus a write-only argument removes the single most abused secret from state in one pull request.
Harden the pipeline identity
The runner that executes terraform apply is the highest-value identity in the pipeline, and static provider keys stored as CI secrets are its weakest link. Google’s IAM guidance for deployment pipelines shows the replacement pattern: GitHub Actions workflows obtain an OIDC token that uniquely identifies the workflow and its repository, and exchanging it through Workload Identity Federation eliminates the maintenance and security burden of long-lived service account keys. HCP Terraform workspaces can do the same, minting tokens that identify the workspace and environment. The trust policy matters as much as the mechanism: pin the issuer, repository, environment and branch in the attribute condition, or any workflow in the organization can mint a valid identity and read state. For the broader program of retiring static keys across providers, see our guide to workload identity federation.
Lock down the state backend
Encryption at rest and access control are separate failures, and you need both. HashiCorp’s baseline for state security is to store state remotely, encrypt it at rest, use access controls to limit who can read it, and audit state access over time. On AWS, the S3 backend encrypts state when you enable the encrypt option, ideally with a KMS key and a key policy that names the pipeline role; on Google Cloud, the GCS backend supports customer-managed encryption keys. Encryption without access control is a locked door in an open hallway — a permissive bucket policy or a disabled public-access block hands the encrypted file to anyone who asks for it. Work through this checklist:
- Enable backend encryption:
encrypt = truewith KMS on S3, or Cloud KMS keys on GCS. - Block public access on the bucket and deny non-TLS requests in the bucket policy.
- Restrict state read access to the pipeline role and named break-glass admins only.
- Enable bucket versioning so a corrupted or maliciously rewritten state can be recovered.
- Turn on object-level logging: CloudTrail data events or Cloud Audit Logs for the state prefix.
- Alert on any
GetObjectcall against the state key outside normal pipeline windows.
Detect and respond fast
Even with every control in place, assume the wrong identity will eventually read state, and instrument for that day. State access leaves traces — S3 data events, control-plane API calls, and writes to the lock table — which makes it a detection problem you can solve with rules you probably already run. The same telemetry that exposes credential abuse also exposes state reads; our CloudTrail runbook for privilege escalation maps cleanly onto state-bucket access patterns. When exposure is confirmed, treat every secret in state as compromised and rotate database passwords, keys and tokens — not only the ones that appear in the latest diff, because state retains historical versions.