vs OPA & Sentinel

Read this if you gate Terraform plans with Open Policy Agent (OPA) or Sentinel today. You keep your policy repository and its run integration. Compliance.tf moves the compliance controls out of policy code and into the modules and the provider, so the plan already carries the secure value before your policies look at it. This page is for the platform lead who owns the Terraform standards and the security engineer who owns the controls.

Summary

Dimension	Compliance.tf	OPA / Sentinel
What it enforces	Framework controls (encryption, logging, access) mapped to clause IDs	Any policy you write: naming, tags, regions, cost, provider restrictions
How it enforces	Module defaults and validations; provider checks before apply	Accepts or rejects a plan
Sets the secure value	Yes	No: can only accept or reject
Policy authoring	None for covered controls	Rego (OPA) or the Sentinel language, maintained by you
Scope	Modules from the compliance.tf catalog, plus hand-written `aws_*` resources through the provider	The entire plan: any resource, any provider
Hand-written resources	Provider checks them; `soft_fail` warns by default, `hard_fail` fails the plan	Evaluated like any other resource
Operational rules	A fixed rule catalog applied at download time, including an allowed-regions allowlist and an instance-type rule that reports denied instance families (configurable `denied` patterns) without blocking	Any rule you can express
Per-environment differences	Each project environment is bound to its own snapshot, so `dev` and `prod` can enforce different control sets	Conditional logic in the policy
Governance and evidence	Snapshot approval, a promotion gate on protected environments, waivers with an expiry, and an audit trail of every posture change	Policy decisions in HCP Terraform run history; policy changes in your Git history
Works outside Terraform	No	OPA: yes (Kubernetes, APIs, services). Sentinel: HashiCorp products
HCP Terraform integration	Works with any runner; no policy set involved	Native policy sets for both Sentinel and OPA

What each tool solves

Compliance.tf produces modules that already carry the controls of the framework you picked. Encryption is on by default, logging is required through input validation, and the provider checks the aws_* resources you write directly. Org-wide operational rules (lifecycle settings, allowed regions) are applied when the module is downloaded.

OPA and Sentinel evaluate a Terraform plan against policy as code. They read the plan and reject one that breaks a rule. They do not change what Terraform produces; they decide whether the plan may proceed to terraform apply.

Where compliance.tf is stronger

It adds the setting instead of rejecting its absence. A policy can refuse a bucket without encryption; it cannot add encryption. With a compliance.tf module the encrypted configuration is in the first terraform plan, so there is no reject, fix, re-plan loop for covered controls.
No policy code for covered controls. No Rego or Sentinel to write, test and keep in step with each AWS resource change.
Controls version with the module source. On a framework endpoint, the same source and pinned version = "5.0.0" are built with the same controls; on your organization's host, the snapshot bound to the environment decides them. A policy repository is versioned separately from the code it governs.
Clause mapping is maintained for you. Each control links to the clauses it maps on the framework pages.
Posture has a promotion path. On a project environment, the control set is an immutable snapshot that is approved, promoted through a gate and recorded. Exceptions are waivers with an expiry rather than edits to a shared policy file.

Where OPA and Sentinel are stronger

Arbitrary policy over the whole plan. Naming conventions, required tags, budgets, provider restrictions, any resource from any provider. Compliance.tf's operational rules are a fixed catalog: the instance-type rule reports literal instance_type values on aws_instance that match its denied patterns and blocks nothing, and the allowed-regions rule acts on modules compliance.tf serves.
Rules about people and context. "Only the networking team can create VPCs" needs a policy engine. Compliance.tf varies controls by framework endpoint and by environment snapshot, not by who runs the plan.
Native in HCP Terraform and Terraform Enterprise. Sentinel and OPA policy sets run as part of the run, with enforcement levels and a record of each decision in the run history.
Reach beyond Terraform. OPA is a general-purpose engine used for Kubernetes admission control, API authorization and more, so Rego skills carry over.
No vendor dependency. OPA is open source; Sentinel comes with HashiCorp's products. Compliance.tf is a paid registry your terraform init depends on.

Use both together

Let compliance.tf set the compliance controls: encryption, access logging, backup retention and the other framework requirements, in the modules and through the provider. Let OPA or Sentinel govern what is specific to your organization and spans every resource: a cost-center tag on everything, team-based approvals for VPCs, rules for providers other than AWS.

Example: the SOC 2 endpoint serves an S3 bucket with encryption, access logging and a public access block. A Sentinel policy requires the environment and cost-center tags on every resource in the plan. Neither layer has to know about the other.

To try it alongside your existing policies, change one module's source: Get started.

Compare approaches
Rule catalog
Promotion and gates
Turn controls on and off
Make the case: build the internal argument for adopting it