compliance.tf vs OPA / Sentinel

What each tool solves

compliance.tf enforces compliant defaults and validations inside Terraform modules. The module itself produces compliant resources. Encryption is enabled by default. Logging is required via input validation. The developer works with a compliant module from the start.

Open Policy Agent (OPA) and Sentinel evaluate Terraform plans against organizational policies. They inspect the plan JSON and reject plans that violate policy rules. They do not change what Terraform produces — they gate whether the plan can proceed to terraform apply.

Where compliance.tf is stronger

OPA and Sentinel can reject a plan that lacks encryption, but they cannot add encryption. Compliance.tf modules include encryption by default, so the developer sees the compliant configuration in their terraform plan output immediately rather than getting a rejection and having to figure out what to add.

This also eliminates policy authoring. OPA requires Rego, Sentinel requires its own policy language, and both need ongoing maintenance. With compliance.tf, covered controls require none.

• No policy drift. Controls are versioned with the module. When you pin version = "5.0.0", the controls for that version are fixed. OPA/Sentinel policies must be maintained separately from the Terraform code they govern, and policy repositories can drift out of sync with infrastructure code.
• The developer sees compliant defaults in their plan output before any policy engine evaluates the plan. With OPA/Sentinel alone, the feedback loop is: write code, run plan, submit to policy engine, get rejection, fix, repeat.

Where OPA / Sentinel is stronger

OPA and Sentinel enforce organizational policies that go beyond compliance controls: naming conventions, required tags, allowed instance types, budget limits, approved regions, provider restrictions. They evaluate every resource in the plan (not just compliance.tf modules) and a single policy repository governs all teams consistently.

• Sentinel is native to Terraform Cloud and Terraform Enterprise. If you use HCP Terraform (formerly TFC), Sentinel policies run automatically as part of the run pipeline with no additional infrastructure. OPA integrates via run tasks.
• Complex conditional logic. "Production workspaces must have encryption; development workspaces can skip it." "Only the networking team can create VPCs." These conditional policies require a policy language — compliance.tf enforces the same controls regardless of context.
• OPA is a general-purpose policy engine used with Kubernetes admission control, API gateways, microservice authorization, and more. Investing in Rego has returns outside Terraform.
• Audit trail built into HCP Terraform. Sentinel and OPA run task evaluations are logged as part of the Terraform run history, providing a built-in audit trail of policy decisions.

When to use both together

Use compliance.tf to set secure defaults for infrastructure resources: encryption, access logging, backup retention, and framework-specific requirements. These controls are built into the module and active from the first terraform plan.

Use OPA or Sentinel on top to enforce organizational policies: every resource must have a cost-center tag, instance types are restricted to the approved list, only us-east-1 and eu-west-1 are allowed, and new VPCs require approval from the networking team.

Example: compliance.tf ensures every S3 bucket has encryption enabled, access logging configured, and public access blocked (SOC 2 controls). Sentinel ensures every S3 bucket has the required environment and cost-center tags and is deployed only in approved regions (organizational policies).

Together, the two layers cover the gap that neither fills alone: compliance.tf sets the defaults; OPA or Sentinel governs everything else.

flowchart TD
    Dev["Developer writes Terraform"]
    CTF["<b>compliance.tf modules</b><br/>Sets secure defaults<br/>Encryption: on · Logging: required · Public access: off"]
    Plan["terraform plan"]
    OPA["<b>OPA / Sentinel</b><br/>Plan evaluation<br/>Tags: required · Regions: approved<br/>Naming: enforced · Costs: within limit"]
    Apply["terraform apply<br/>compliant + policy-conformant deployment"]

    Dev --> CTF --> Plan --> OPA --> Apply

Summary

Need to make the case to your team? Internal advocacy guide.