Policy as Code Tools Using OPA and Rego for Infrastructure Governance

TLDR

Open Policy Agent and its Rego language have become the default foundation for policy-as-code across Kubernetes, Terraform, and CI/CD pipelines. But "OPA tooling" now spans a fragmented set of products, some built on top of it, some evaluating the same Rego rules differently, and one major commercial layer currently being wound down. This post covers the real tools worth knowing in 2026, including a governance update every team evaluating OPA needs to see first.

Policy as code has become table stakes for infrastructure governance. Almost every team running Terraform, Kubernetes, or a multi-cloud environment at any real scale has some version of "policies that block bad deployments before they ship" running somewhere in the pipeline. What's less settled is which tool actually runs those policies, since "OPA" and "Rego" are used as umbrella terms for a genuinely fragmented ecosystem beneath the surface.

This post covers the tools that actually matter in 2026: what each one does, where it fits, and one governance change that affects how confidently teams should evaluate the commercial layer around OPA right now.

What Does the Styra-Apple Deal Mean for OPA in 2026?

Open Policy Agent went through a real transition in August 2025. Apple hired OPA's three original creators, along with several senior engineers from Styra, the company that built and commercialized OPA, without acquiring Styra itself. Styra's commercial products, Styra DAS and Enterprise OPA, are being sunset, with their code folded into the community-maintained OPA project.

OPA itself isn't going anywhere. It remains a CNCF-graduated project, with governance and licensing unchanged, the same maintainer list aside from employer changes for those who joined Apple, and the same monthly release cadence, as confirmed directly by the project itself. Production use remains broad at Netflix, Google Cloud, Goldman Sachs, T-Mobile, and hundreds of other organizations, and that adoption hasn't shifted since the Apple-Styra transition, since none of it depended on Styra's commercial layer to begin with.

The practical takeaway: trust OPA and Rego as a foundation; they're stable and independently governed, but don't evaluate Styra's commercial products as an ongoing option. Any tool built on raw OPA rather than Styra's sunset layer isn't affected by this at all.

1. StackGuardian

StackGuardian runs two policy engines side by side rather than forcing a single choice.

Key features:

• Tirith: StackGuardian's own JSON-based framework; three-part structure (meta, evaluators, eval_expression) combining checks with &&, ||, ! logic
• Native OPA support: source Rego policies directly from a Git repo, with an OPA Deciding Query pointing at the rule that returns the final decision
• Three scope levels: organization-wide, specific Workflow Groups, or individual Connectors tied to a cloud account
• Five rule statuses: Pass, Fail, Warn, Approval Required, Unevaluated, each independently configurable per policy
• NoCode Policy Builder: generates the same Tirith output through a UI for teams that don't want to write JSON or Rego

Pros:

• Covers both Terraform plans and cross-system policies (Kubernetes, API gateways) under one platform
• No forced choice between writing Rego and using a simpler format
• Every evaluation logs automatically, with no separate audit tool required
• Scope model prevents a sandbox policy from accidentally governing production

Pricing: Workflow-based, not tied to resource count under management. Current tiers and details at stackguardian.io/pricing.

2. Open Policy Agent (OPA)

OPA is the foundation on which the rest of this list builds: a general-purpose, CNCF-graduated policy engine that decouples decision-making from enforcement.

Key features:

• Queried over HTTP or embedded directly into an application
• Evaluates Rego, a declarative language purpose-built for hierarchical, structured data
• Runs identically across Kubernetes, Terraform, API gateways, and CI/CD
• A policy written once in Rego can run unchanged wherever OPA is deployed

Pros:

• Vendor-neutral, no single company controls the roadmap
• Massive existing ecosystem of policy libraries and integrations
• One policy language across every system that queries it

Cons:

• Real Rego learning curve for teams coming from YAML or general scripting
• No built-in scope management, approval routing, or audit trail; all of that gets built separately

Pricing: Free and open source, self-hosted. No commercial tier since Styra's enterprise offerings are sunsetting.

3. Conftest

Conftest is a small, open-source CLI from the OPA project itself, built for teams that want OPA's policy model without having to stand up a server.

Key features:

• Evaluates Rego policies against structured config files directly
• Accepts Terraform plan JSON, Helm charts, Kustomize output, Kubernetes manifests, and Dockerfiles as input
• Same Rego rules used for OPA proper run unchanged in Conftest
• Ships as a single binary, drops into CI with a few lines of YAML

Pros:

• No server to run or maintain
• Fast to add as a pass/fail gate on a pull request
• Policy logic written once can graduate to full OPA later without a rewrite

Cons:

• No scope management, drift detection, or approval workflow on its own
• Best paired with something else for teams that need those pieces

Pricing: Free and open source.

4. OPA Gatekeeper

Gatekeeper is a Kubernetes-native policy controller built directly on OPA, optimized for one job: admission control inside a cluster.

Key features:

• Constraints defined as Kubernetes Custom Resource Definitions
• Rego policies underneath, evaluated at admission time
• Rejects non-compliant workloads before creation, not after
• Common uses: restricting container images, enforcing naming conventions, requiring specific labels or annotations

Pros:

• Purpose-built for Kubernetes, tightly integrated with the cluster API
• Blocks violations before they exist rather than flagging them later
• Backed by the CNCF community, not a single vendor

Cons:

• Doesn't extend to Terraform plans or cloud-provider configuration outside the cluster
• Teams managing infrastructure beyond Kubernetes typically need to pair it with a broader tool

Pricing: Free and open source.

5. HCP Terraform's OPA Policy Sets

HashiCorp's own platform supports OPA as an alternative to Sentinel, its proprietary policy language, through Run Tasks.

Key features:

• Teams already on HCP Terraform can write Rego instead of Sentinel
• Same plan-time enforcement point as native Sentinel policies
• Runs inside HCP Terraform's existing Run Task framework

Pros:

• No proprietary policy language required for teams that prefer open tooling
• Existing Rego policies from elsewhere may port over with minimal changes

Cons:

• OPA policies here still only evaluate plans running through HCP Terraform specifically
• A team wanting the same Rego policy to also govern Kubernetes or a CI pipeline maintains that enforcement separately

Pricing: Tied to the HCP Terraform tier, not priced separately. As of mid-2026, tiers run Essentials at $0.10 per managed resource/month, Standard at $0.47, and Premium at $0.99, all billed hourly on peak resource count. Audit logs are limited to Standard and Premium; Enterprise (self-managed) is quote-based. A free tier covers up to 500 managed resources.

Should You Still Consider Styra DAS or Enterprise OPA in 2026?

Styra DAS and Enterprise OPA were, for years, the default answer for teams wanting to manage OPA at scale, centralized policy authoring, compliance auditing, and runtime enforcement across a fleet of deployments. That's no longer a forward-looking recommendation.

Following Apple's hiring of Styra's core team in August 2025, both products are being wound down, with their capabilities merging into the community OPA project over an unspecified timeline. Existing customers aren't left with nothing overnight, but there's no ongoing commercial roadmap and no new subscriptions being sold.

Teams starting fresh in 2026 shouldn't plan around this layer. The safer path is to build on OPA directly or to choose a platform that layers management and enforcement on top of the open project, not a sunset commercial one.

Which Policy as Code Tool Should You Actually Use?

The decision usually comes down to how much of the governance surface is Kubernetes-only versus spread across Terraform, cloud accounts, and CI/CD. Gatekeeper fits the former; Conftest, raw OPA, or a broader platform fit the latter.

It also depends on how much Rego expertise the team actually has or wants to build. Raw OPA and Conftest both assume comfort writing and debugging Rego. Teams without that appetite get more from a platform offering a no-code or JSON-based alternative alongside native OPA support, so policy authoring doesn't become a bottleneck concentrated in one or two engineers.

The last factor is whether the team needs a managed platform to handle scope, approval routing, and audit logging, or just a policy evaluation step within an existing pipeline. Conftest and Gatekeeper are both narrow by design, a feature for teams that already have the surrounding infrastructure. Teams that don't have that yet get more out of a platform that provides scope, drift detection, and audit trails, all within the same system that runs the policies.

Where Does This Leave Policy as Code Going Into 2026?

OPA and Rego remain the right foundation for policy-as-code in 2026, regardless of what's happening commercially around Styra. The project itself is stable, CNCF-governed, and unaffected in any technical sense by the transition. What changed is which layer sits on top of it, and teams choosing tools right now should weigh that layer on its own merits rather than assuming the ecosystem around OPA looks the same as it did two years ago.

For teams that want both paths available without committing to one, a JSON-based engine for straightforward IaC and workflow policies, and full OPA support for anything that needs to run across systems, StackGuardian's policy engine runs Tirith and OPA side by side under the same scope model, rule actions, and audit trail.

FAQs

1. Do Sentinel policies in HCP Terraform port to OPA and Rego?

No. Sentinel is a proprietary policy language specific to HashiCorp's platform, and it doesn't translate automatically to Rego. Teams switching from Sentinel to OPA, whether inside HCP Terraform's own OPA-based Run Tasks or on another platform, need to rewrite the underlying policy logic rather than migrate it directly.

2. Can StackGuardian's Tirith and OPA policies enforce the same rule, or do they need to be written twice?

They're separate engines with different syntaxes, JSON for Tirith versus Rego for OPA, so the same rule needs to be authored once in each format if a team wants both available. What doesn't duplicate is the scope model, rule actions, and audit trail, which apply identically to policies from either engine within the same Workflow Group.

3. Is Conftest a replacement for a full policy management platform?

No. Conftest is a lightweight CLI for running Rego checks against structured config files in a CI pipeline, it has no scope management, approval routing, or audit logging built in. Teams needing those capabilities typically pair Conftest with a broader platform or graduate to running OPA as a managed service.

4. Does OPA Gatekeeper work for governing Terraform-provisioned cloud resources?

Not directly. Gatekeeper is Kubernetes-native, enforcing policy at admission time inside a cluster. It has no mechanism for evaluating a Terraform plan or a cloud-provider configuration outside Kubernetes, so teams managing infrastructure beyond a cluster typically need Gatekeeper plus a separate tool for the rest.

5. What happens to existing Styra DAS or Enterprise OPA policies if a team doesn't migrate?

Existing customers aren't cut off immediately, but there's no ongoing commercial roadmap or new subscriptions being sold following the products' sunset. Policies written for Styra DAS specifically will need to move to community-maintained OPA or another management layer over time, since Styra's capabilities are being folded into the open project rather than continuing as a standalone commercial product.