OpenTofu State Encryption Prompt
Enable OpenTofu's native client-side state and plan encryption — key providers (KMS/PBKDF2), key rollover, fallback for reading old state, and CI wiring — so sensitive values never sit in plaintext in your backend.
- Target user
- Platform teams hardening IaC state at rest
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior platform-security engineer who has rolled out OpenTofu's native state encryption across production workspaces without losing access to existing state.
I will provide:
- My OpenTofu version and backend (S3/GCS/azurerm/remote)
- Cloud KMS availability (AWS KMS, GCP KMS, Azure Key Vault) or whether I need a passphrase
- How many workspaces/states and who can read the backend today
- CI/CD: where tofu runs and how it authenticates
Your job:
1. **Threat model** — clarify what state encryption protects against (plaintext secrets/outputs readable by anyone with backend/bucket access) and what it does NOT (it is not a substitute for least-privilege on the backend itself).
2. **Key provider choice** — compare the `aws_kms`/`gcp_kms`/`openbao`/`pbkdf2` key providers for my environment; recommend KMS over passphrase for production and explain why passphrase rotation is painful.
3. **Configuration** — write the `terraform { encryption { ... } }` block: the key provider, the `method` (AES-GCM), and `state {}` / `plan {}` enforcement. Show whether to set `enforced = true` and the consequences.
4. **Migrating existing state** — the critical part: configure the new method while keeping the old/unencrypted read path as `fallback` so `tofu init`/`plan` can read current state, then run a single migrating apply, then remove the fallback. Give the exact ordered steps and a verification check.
5. **Key rollover** — add a new key as primary with the old key as fallback, re-encrypt via an apply, then retire the old key. Show the config for each phase.
6. **CI/CD** — ensure runners have KMS decrypt permission, keys are not logged, and `enforced = true` so an unencrypted state can never be written by accident.
7. **Disaster recovery** — what happens if the KMS key is deleted or access is lost; how to back up state and key material safely, and how this interacts with state backups.
8. **Rollout plan** — sequence workspaces low-risk first, verify each, and keep fallback until confirmed.
Output as: (a) annotated encryption block per key provider, (b) the ordered migrate-with-fallback runbook, (c) the key-rollover phase configs, (d) CI permission + safety notes, (e) a DR section.
Keep a verified fallback/back-out path at every step; losing the key without a backup means losing the state.