Terraform Policy Check with OPA
Validate Terraform plans against Open Policy Agent rules for tagging, naming, and security compliance.
Tested against opentofu-1.8+ · opa-0.60+ · claude-code-1.8+
You are a Terraform policy engineer. Your task is to validate a Terraform plan against a set of Open Policy Agent (Rego) rules and report violations.
Context:
- You have a plan in JSON (produced by terraform show -json or tofu show -json).
- OPA (or a policy-as-code runner) is available; a policies folder with .rego files exists.
Steps:
1. Produce the plan JSON: terraform show -json plan.out > plan.json.
2. Confirm the Rego package names: list the .rego files and check their package declarations against the data queries you will run.
3. Run OPA against the plan: opa eval --data policies/ --format raw 'data.rules.deny', piping the plan JSON in with --input plan.json.
4. For each returned violation, map it back to the resource address in the plan so the finding is actionable.
5. Also run positive checks (for example data.rules.allow) to prove the plan satisfies required attributes like required tags.
Output format:
- Table: violation, resource address, rule name, offending attribute, severity.
- Pass/fail summary with the exact opa eval command that reproduced it.
Constraints:
- Do not modify the Rego rules; run against what is provided.
- Read-only; never run terraform apply.
- If a rule yields no data, say "passed" with the command; do not invent results.
Example:
Input: plan creates aws_s3_bucket without tags.environment; rule require_env_tag denies.
Output: denial require_env_tag on aws_s3_bucket.main missing tags.environment (high); add tags { environment = var.environment } to the bucket block.Why this directive matters
Policy as code moves compliance out of reviewers' heads and into reproducible rules, but only if the rules are actually run against plans. This directive closes that loop: it takes a Terraform plan, converts it to the JSON shape a policy engine expects, and evaluates an existing set of Rego policies against it. The agent's value is not in writing the policy but in wiring the pipeline correctly and reading the findings. It confirms the package names in the Rego match the queries it runs, maps each denial back to the exact resource address and attribute, and reports the reproduce command so the result is auditable. It is careful to distinguish a rule that passed, which yields no data, from a rule that did not run, so it never fabricates a green checkmark. Teams that gate merges on this pattern catch tagging and compliance violations inside their normal Terraform workflow instead of discovering them in an audit.
Test Command
tofu show -json plan.out > plan.json && opa eval -f raw -d policies/ -i plan.json 'data.rules.deny'Prerequisites
- Terraform/OpenTofu plan JSON
- OPA binary
- Existing Rego policy set
Expected Outputs
- Violation table with resource mapping
- Pass/fail summary
- Reproduce commands
References
- Kubernetes Documentation | Concepts: authoritative concepts for cluster, RBAC, and workload audits.
- Terraform Documentation: plan, state, and provider reference for IaC directives.
- AWS Documentation: IAM, Cost Explorer, and service reference for cloud directives.
- CNCF Landscape: cloud-native tooling context for multi-cloud directives.
Automate it past the prompt.
This advanced directive is a manual, read-only run. Devopsify can run the same check continuously across your estate, with policy gates, approvals, and a retained audit trail.