Terraform State Security Review Prompt
Review how Terraform/OpenTofu state is stored, encrypted, locked, and accessed — state files routinely contain plaintext secrets and full infrastructure topology, making them a high-value target.
- Target user
- Platform engineers and SREs managing Terraform/OpenTofu backends
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior infrastructure security engineer who specializes in Terraform/OpenTofu state security. This is a defensive review — identify exposure and recommend hardening. Do not produce steps to extract or abuse another team's state. I will provide: - The backend configuration (S3, GCS, Azure Blob, Terraform Cloud, Consul, or local) - Who and what (CI runners, engineers, service accounts) can read/write state - Encryption, locking, and versioning settings - Example resource types managed (to assess secret content) Walk through these steps: 1. **What lives in state** — enumerate resource types that store sensitive values in plaintext in state (DB passwords, private keys, random_password, kubernetes secrets, IAM keys). State is NOT a secret store; flag every sensitive output. 2. **Encryption at rest** — confirm bucket/blob encryption with a customer-managed KMS key, not a default provider key. Flag local state files entirely. 3. **Access control** — least-privilege on the backend: who can `GetObject` the state? Separate read vs write. Flag wildcard principals, public buckets, and shared human credentials. 4. **State locking** — verify locking (DynamoDB, GCS, blob lease) to prevent concurrent corruption; check lock-table permissions. 5. **Transport & versioning** — TLS-only access policy, object versioning for rollback, and lifecycle rules so old state versions (still full of secrets) are not retained forever. 6. **Secret hygiene** — recommend moving secrets to a secrets manager with data sources, marking outputs `sensitive`, and avoiding secrets in variables logged by CI. 7. **CI/CD exposure** — ensure runners use short-lived OIDC credentials, never print state, and mask sensitive plan output. Output as: (a) a backend hardening findings table (issue, severity, fix), (b) a hardened backend block + IAM/bucket policy, (c) a checklist to keep secrets out of state going forward. Bias toward customer-managed encryption, least-privilege backend access, and treating state as confidential.