Open-source alternative to Sentinel policy as code: the short answer
Open Policy Agent with Rego can replace Sentinel policy as code. The two self-hosted routes are Terrakube's OPA extension, which adds policy checks to runs, and Atlantis policy checks, which run conftest against the plan output. Sentinel policies must be rewritten in Rego before they can run, because the two languages differ in syntax, data access and how a decision is returned. No translation is automatic, so every policy needs to be re-stated, tested and signed off by its owner. The first decision is which workflow the team runs. If engineers start runs from the Terraform or OpenTofu CLI and want policy results next to workspaces, variables and run history in one web UI, Terrakube is the closer fit. If infrastructure changes are proposed and reviewed as pull requests, Atlantis is the closer fit.
The enforcement model differs between the two. Atlantis policy checking is switched on with the --enable-policy-checks server flag. Conftest evaluates Rego policies against the plan, and a failing plan blocks apply until a later commit fixes it or the policy owners approve the change. That approval step is a design task: the team must name the owners, decide how approval is recorded and agree who may override a failed check. Confirm the same behavior for Terrakube's OPA extension in its Terrakube documentation, including whether a failed check stops the run and who can approve it. Do not assume that HCP Terraform's enforcement levels map one to one onto either tool.
Before cutover, inventory every Sentinel policy and record which workspaces it governs, what each one checks and whether it is tied to a compliance control. Build a set of sample plan files, one passing and one failing for each policy, and run the Rego versions against them in CI. Run the new checks in parallel with HCP Terraform for a period agreed with the policy owners, then compare results. Cost here is mostly staff time for policy authors, reviewers and the platform team, and it rises with the number of policies, their complexity and how thin the existing test coverage is. Ask any implementation partner for the policy count, test approach and approval design in writing before work starts.
Which Sentinel capabilities map to Open Policy Agent and which need confirming
This table maps each Sentinel-related capability to the open-source option that covers it, using Atlantis policy checking and the Terrakube README. Where the sources do not confirm a behavior, the cell says what to verify in your own environment before you rely on it. Read the true and false marks as confirmed by the documentation, and the dashes and check-ups as open items for a proof of concept.
| Capability | Atlantis with conftest and Rego | Terrakube with OPA extension |
|---|---|---|
| Policy evaluation against the plan | Yes | Terrakube extensions add OPA policy checks to runs, per its README |
| Blocking applies when a policy fails | Failing plans block apply until a later commit fixes them or policy owners approve, per the Atlantis documentation | Confirm in your Terrakube version that a failed OPA check stops the run before apply |
| Override by a policy owner | Approval by policy owners is documented, so confirm which users or teams may approve | Not confirmed by the sources; confirm how an override is granted and audited |
| Policy sets applied across workspaces | Policies are enforced per repository and project through atlantis.yaml, so confirm how shared policy sets are distributed | Not confirmed by the sources; confirm whether one policy can attach to many workspaces |
| Reporting results in the run or pull request | Policy output is posted to the pull request, which the Atlantis guide describes for plans | Run output appears in the Terrakube run view; confirm the detail shown for OPA results |
| Translation of Sentinel rules to Rego | Rego policies run through conftest, so each Sentinel rule needs a rewritten equivalent | Same Rego policies apply, so the translation effort is the same on both platforms |
Terrakube OPA extension or Atlantis conftest checks: which fits
Both options replace Sentinel's role of checking plans before apply with Open Policy Agent (OPA) policies written in Rego. They differ in where the check runs: inside a Terrakube run with its workspace model, or inside an Atlantis pull request workflow. The right choice depends on whether your team works from a run UI or from pull requests.
Terrakube OPA policy extension
Terrakube extensions add tools such as OPA policy checks to runs, so the policy result sits in the same run record as the plan, state and approvals. This suits teams that already manage organizations, workspaces, a private registry and group-based permissions in one place. The trade-off is that you adopt Terrakube's run and workspace model as the control plane. Check which policy inputs the extension exposes, how a failed check blocks apply, and who may change the policy repository.
Atlantis conftest policy checks
With the --enable-policy-checks server flag, Atlantis runs conftest policies written in Rego against the plan output and blocks apply on a failing plan. A later commit that fixes the plan, or approval from policy owners, is required to proceed. This fits teams whose review already happens in pull requests and who want policy results beside the plan comment. The trade-off is that you give up a hosted run UI and workspace view. Confirm how policy owner approval is granted and recorded in your Git host.
Policy input and plan parsing
Sentinel policies read the plan through its imports, while OPA policies read the plan JSON that you supply to the check. Whichever option you choose, write a small set of rules that inspects the rendered plan for resource types, public exposure and tagging, then test them against sample plan files. Confirm the exact plan JSON format each tool passes to Rego before you port any rule.
Policy repository and ownership
Neither product supplies a policy library, so your team must write, version and review the Rego rules. Store them in a separate repository with its own owners, so that changing a policy requires a different approval path than changing infrastructure code. Decide who may approve an override in each option, and document it in the change process your auditors will read.
Testing and rollout of policies
Run new policies in a non-blocking mode against recent plans before they gate applies. Keep a set of passing and failing plan fixtures in version control and run them in CI. Plan for the failure mode where a broken policy blocks every run, and document how to disable a rule safely with a recorded approval.
Operating and supporting the checks
Both options require the platform team to keep the policy runner, Rego libraries and tool versions current, and to monitor them in the runtime environment you control. Ask a provider to quote the work of writing the initial policies, the test fixtures and the ongoing maintenance as separate line items. Confirm the support path for each tool version you pin.
How Sentinel policies translate to Rego, and what does not translate
Each Sentinel policy has to be re-expressed as Rego, because OPA evaluates only the data it receives and the rules are written in a different language. Start with an inventory: for every policy set, record the policy file names, what each rule checks, the enforcement level it is attached to, and the Terraform resource types it touches. Then list the inputs each rule reads, such as resource attributes (instance type, encryption flags), tags, and provider settings like default tags or region. Sentinel reads through its own imports, so a rule that depends on a Sentinel import has no direct equivalent and must be redesigned around the plan JSON. Before writing any Rego, confirm the input shape your chosen option supplies: the path to planned values, how resource changes and prior values appear, and whether variables and tags are included.
Test every translated rule against saved plans before it blocks anything. Save plan files from representative changes, convert them to JSON, and run the Rego locally with conftest or opa against passing and failing fixtures. Keep a fixture for each Sentinel rule so outcomes can be compared side by side: a change Sentinel rejected should be rejected by the Rego, and a compliant change should pass. Include edge cases such as resources being created versus updated, unknown values that only appear at apply time, and resources created through modules. For Atlantis, the policy checking documentation describes how conftest results gate applies, so run the same plans through that path in a non-production repository before enforcement.
The approval model is what translates least directly. Sentinel's enforcement levels (advisory, soft mandatory and hard mandatory) let a policy owner override a failing check in HCP Terraform, and that override path does not carry over automatically. Atlantis blocks applies on failing policy until a later commit fixes the plan or policy owners approve, so each Sentinel level needs an explicit decision: which failures block, which only warn, and who may override. Confirm how the Terrakube OPA extension reports results and whether it can produce the same outcomes. Expect gaps in functions that depend on HCP-specific run data or external calls, and treat each one as a redesign item. Write the level-by-level mapping and have policy owners sign it off before migration, because an approval rule that exists only in code is hard to audit.
Migrating Sentinel policy sets to OPA without a gap in enforcement
This sequence moves each Sentinel rule to an Open Policy Agent check in stages, so enforcement stays continuous from inventory through blocking. The output is a tested set of Rego policies, a documented override process and an evidence record that shows when the Sentinel policy set can be safely cancelled.
Export and inventory Sentinel policy sets
For each HCP Terraform workspace, list the Sentinel policy sets attached to it, their enforcement level (advisory, soft-mandatory or hard-mandatory), and the workspaces that share each set. Save the Sentinel source for every rule, since the source is the reference for the translation. Confirm with HashiCorp's API documentation how to read policy set attachments in your organization, because the export path is outside this guide. Done when you have a table with one row per rule, its attached workspaces and its enforcement level, reviewed by the platform team.
Assign an owner to each rule
Name one accountable owner for every Sentinel rule, usually someone from security, compliance or the platform team who can decide what the rule should enforce. Ask each owner to state the intended behavior in plain language before anyone writes Rego. These owners are also the people who approve overrides later, so confirm they accept that role. Done when every rule in the inventory has a named owner and a written intent statement that the owner has signed off in your change system.
Rewrite rules in Rego and test them
Translate each Sentinel rule into Rego, the policy language used by Open Policy Agent. The two languages read input differently: Sentinel uses its own imports to read the plan, while conftest evaluates the plan JSON produced by
tofu show -json(orterraform show -json). Build a test workspace with sample plans that cover both passing and failing cases for each rule. Done when every Rego policy returns the same allow or deny result as its Sentinel rule on every sample plan, and the policies and test cases are stored in version control.Enable the OPA check in advisory mode
Turn on the policy check in the target platform without letting it block applies. In Atlantis, policy checking is enabled with the
--enable-policy-checksserver flag and runs conftest policies against the plan output, but its documented behavior blocks applies on failing plans, so confirm whether your version offers a report-only option. If it does not, run conftest as a separate, non-blocking step in a custom workflow. In Terrakube, confirm how the OPA extension can report results without failing the run. Done when every workspace in scope posts OPA results on each plan and no apply has been affected by the check.Compare OPA and Sentinel results over time
Run both checks against the same plans for a comparison period that the rule owners agree on, and record every difference. Each mismatch is either a translation error to fix in Rego or a Sentinel behavior the owner decides to keep or drop. Log the plan identifier, both results and the owner's decision for each case. Done when the owners have signed off that no unexplained differences remain for in-scope rules and every workspace in the inventory has been covered.
Switch OPA to blocking and document overrides
Set the OPA check to enforce, so failing plans cannot apply. Write the override process before the switch. In Atlantis, a failing plan stays blocked until a later commit fixes it or the policy owners approve, so record who may approve, how approval is captured and where it is kept. Configure Terrakube's OPA extension to match the same rules, and confirm the setting in its documentation. Done when a test pull request with a deliberately failing change is blocked, a test approval is recorded, and the runbook is published to the team.
Cancel Sentinel and keep the evidence
Detach each Sentinel policy set only after blocking mode has run cleanly and the override runbook is in use. Confirm that no workspace still references the set, then cancel it in HCP Terraform. Keep the Sentinel source, the Rego equivalents, the comparison log, the owner sign-offs, the block and override records and the plan outputs from the blocking period in a location outside the platform being retired. Ask your compliance lead how long these records must be retained. Done when the policy set is gone from every workspace and the evidence pack is filed where auditors can find it.
Policy owner approval and override in the open-source model
In Atlantis, a failing policy check blocks atlantis apply for that pull request. The block lifts in one of two ways: a later commit changes the configuration so the plan passes, or designated policy owners approve the failing result. Enable the checks with the --enable-policy-checks server flag, then decide before go-live who those owners are. Name them by team or group rather than by individual, keep the list in version control, and make sure the approval rule is tied to the people who own the control objective, not the people who wrote the Rego. Atlantis records who approved only as far as the pull request platform records it, so the approval mechanism depends on your Git provider's review rules and on the Atlantis configuration you set. Confirm exactly how your provider and Atlantis version record an override before you describe it to an auditor.
The main risk is concentration of duties. If the engineers who write the infrastructure change, write the Rego policy, approve the policy exception and merge the pull request are the same small group, a failing check can be waved through without independent review. Separate these roles where you can. Require that the approver is not the author of the pull request, restrict who can merge to protected branches, and treat the policy repository as a controlled change of its own, with its own reviewers and branch protection. Anyone who can push to the policy repository can weaken a control, so limit write access to that repository to the policy team and log its history.
Terrakube's OPA extension can also block runs on policy results, but the override path is a different design and its audit behavior is not something to assume. Before relying on it as an audit trail, confirm in the Terrakube documentation, and in a test environment, how the extension records a policy override, which identity is stored with it, and which groups in Dex-backed authentication are allowed to grant one. Ask the same questions of Atlantis for your own provider. Document the answers in your change management procedure so the control owner can show who approved what, when, and under which policy version.
Running OPA checks beside the rest of HCP Terraform during the transition
Most teams cannot move every workspace off HCP Terraform on the same day, so Sentinel and OPA checks will run side by side for a period. The cards below cover the decisions that keep both systems consistent, from shared policy code and rule IDs to state location, VCS wiring and ownership.
One policy repository for both systems
Keep the Rego policies in a single repository that both the Terrakube OPA extension and Atlantis's conftest step can reference, instead of maintaining copies inside each platform. Translated Sentinel rules then change in one place and reviews happen once. Confirm which branch or tag each system pins, so a policy change does not reach one platform before the other.
Stable rule IDs across both systems
Give every translated rule an identifier that stays the same in Sentinel and Rego, so an audit finding can be traced to the same control in either system. A reviewer should be able to match a failing HCP Terraform run to a failing OPA check by ID. Record the mapping in a table kept with the policy repository.
State stays in its current backend
Workspaces that have not moved should keep their HCP Terraform state, and workspaces that have moved should point at a backend you control. Do not let a single workspace hold state in two places, because a second copy will drift. Confirm that each Terrakube or Atlantis workspace uses its own state key and that no migrated workspace still writes to HCP Terraform.
VCS connections on the same repositories
If HCP Terraform and Terrakube both watch the same repository, a single pull request can start two plans and post two sets of results. Decide which system owns each directory or project during the transition and disable the other trigger. Confirm that webhooks, branch filters and working directories match on both sides.
Duplicate notifications and conflicting results
Dual running can produce two pass or fail outcomes for the same change, for example when Sentinel passes but a converted Rego rule fails on an edge case. Decide in advance which result gates the merge and how a disagreement is resolved. Test a set of known plans through both systems and confirm that notifications go to one channel with clear labels.
Named owners for each system
Assign one team to own the HCP Terraform policy set and another to own the OPA checks, and name the person who approves changes to shared policies. Without that split, a policy edit can land in one system and never reach the other. Confirm who can override a failing check in each system and how that approval is recorded.
Questions teams ask before replacing Sentinel with Open Policy Agent
How long does it take to translate Sentinel policies into Rego?
The effort depends on how many Sentinel policies you have, how much logic each one contains, and how many of them depend on the shape of the Terraform plan JSON. A small set of rules that check tags, allowed regions or instance types is usually simpler than policies that compare resources across the whole plan or read external data. Your team should inventory every policy, its enforcement level and the workspaces it covers before estimating. Ask any partner for a written scope that lists the policies, the test cases and the review steps, so the estimate follows from that list rather than a general figure.
Can our own engineers translate Sentinel policies to Rego without outside help?
Yes, many teams do this in-house, especially when a few engineers already know Terraform well and can learn Rego. The work is mostly reading each Sentinel rule, deciding what it should check in the plan JSON, and writing the equivalent Rego with tests. The harder part is agreeing on what each rule means, which is a governance task rather than a syntax task. If you lack Rego experience or a test workspace, bring in help for the first few policies so your team learns the patterns and builds a reusable test set.
What skills, people and samples does a Sentinel to Rego migration need?
Plan for four inputs:
- Rego skills on the platform team, with someone who can write and debug policies and unit tests
- Named policy owners who approve each rule's intent and who can approve overrides
- A test workspace where you can run
terraform planortofu planand check the output against each policy - Sample plan JSON files, generated from real but non-production configurations, covering creates, updates and deletes
Having these ready before work begins shortens the review cycle. Confirm with your platform team which tools and sample files they can access under your data handling rules.
What recurring costs remain after moving policy checks to Open Policy Agent?
Open Policy Agent itself is open source, so the recurring costs are the components around it. These include the compute that runs your Terrakube or Atlantis service, the database or state storage those platforms need, backups and monitoring, and the staff time to upgrade the platform, maintain policies and handle exceptions. Compared with a hosted service billed per run or per resource, these costs are paid to your own cloud provider and your team or partner, so they rise with the number of workspaces and pull requests. Ask any quote to separate one-time setup from ongoing support, upgrades and testing.
Can Open Policy Agent reproduce every rule written in Sentinel?
Not necessarily. OPA with Rego covers most plan-based checks, such as deny rules on resource attributes, required tags and naming patterns, and it can read external data when you supply it. Some Sentinel features, such as specific imports or cost and policy-set functions that depend on the HashiCorp platform, may have no direct equivalent and need a redesign. Review each policy against what it actually enforces, mark the rules that need a different approach, and confirm the behavior of the Terrakube OPA extension or conftest setup with your own sample plans before you retire any Sentinel rule.
How does the override process differ from Sentinel's soft-mandatory approach?
In Sentinel, enforcement levels such as advisory, soft-mandatory and hard-mandatory decide whether a run can proceed and who can override a failure. With Atlantis, policy checking runs conftest against the plan output with Rego policies, and a failing plan blocks apply until a later commit fixes it or the policy owners approve the override. Terrakube's OPA extension is configured within its run workflow, so confirm how it handles overrides and approvals in your version. Document who approves overrides, how approvals are recorded in pull requests or the run log, and how this matches your audit trail requirements.
Does moving to Rego change the controls auditors will review?
It can change how evidence is produced, so plan for it early. Your policy repository, test results, approval records and plan logs become the evidence, rather than a vendor console. Auditors will ask whether each rule still enforces the same intent and whether overrides are traceable. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or attestation. Ask your auditor which evidence they expect before you finalize the Rego policies.
How DeployOpen scopes, delivers and supports a Sentinel to OPA migration
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Sentinel to Open Policy Agent move, that means translating your policy set into Rego, wiring checks into your run platform, and handing your team the evidence and runbooks to keep it running.
How we scope
- Inventory every Sentinel policy, its enforcement level and the workspaces it covers
- Confirm whether runs happen in Terrakube with its OPA extension or in Atlantis with conftest
- Agree written deliverables, test cases and timelines before any policy work starts
How we build
- Rewrite each in-scope Sentinel policy as Rego and test it against sample plan JSON
- Configure the chosen check path, including Atlantis --enable-policy-checks or Terrakube extensions
- Set policy-owner approval rules so overrides follow your change control, and test failing plans
How we hand over
- Document each translated policy, its test cases and any behavior that differs from Sentinel
- Provide a runbook for updating Rego policies, reviewing failures and recording policy-owner approvals
- Walk your platform and security teams through the setup and confirm the handover in writing
How we support
- Engagements are fixed-scope, with changes to scope agreed in writing before work resumes
- Ongoing support, upgrades and continuous policy testing are available as a retainer
- Ask any provider, including us, to confirm how policy evidence is retained for your auditors
