Open Policy Agent (OPA)

What it is

Open Policy Agent (OPA) is a general-purpose policy engine that decouples policy decisions from application code. You write rules in Rego (OPA's declarative query language), feed OPA structured input (JSON), and it returns a decision. It's used to enforce policy across Kubernetes admission control, API authorization, CI/CD pipelines, microservice authz, and infrastructure-as-code validation. It doesn't ship as a Kubernetes-specific tool — Kubernetes is just one of many systems that call into it, typically via the Gatekeeper project for admission control use cases.

Who builds it and why

OPA is a CNCF graduated project, which means it's cleared the bar for production usage, governance maturity, and broad adoption across multiple organizations — not a single-vendor pet project. 584 contributors and an active commit history (latest activity mid-2026) indicate it's not stagnant. Styra, the company founded by OPA's original creators, drives a large share of core development and maintains a commercial layer on top (Styra DAS), but the project itself is fully open governed under CNCF, not gated behind a single vendor's roadmap. The motivation behind it: policy logic was getting hardcoded into every app, gateway, and CI script differently — OPA centralizes that into one engine and one language.

Production readiness signal

11,924 GitHub stars and 584 contributors is a solid, mature signal for a policy engine — this isn't a fringe project. Apache-2.0 licensing removes legal friction for enterprise adoption. Latest release v1.18.1 suggests a project well past 1.0 with a stable API and versioning discipline. Written in Go, which fits the cloud-native ecosystem it lives in (easy to embed, cross-compile, containerize). CNCF graduated status is itself a strong production signal — it means audited processes, diverse maintainership, and adoption evidence were already vetted by the CNCF TOC. The lack of a public founding date or maintained description is a documentation gap, not a red flag on the code itself.

Who should use this

• Platform teams enforcing Kubernetes admission policies (via Gatekeeper) — image provenance, resource limits, label requirements, network policy compliance.
• Teams needing centralized authorization logic across microservices instead of duplicating auth checks in every service.
• Security/compliance teams that need policy-as-code they can version, test, and audit independently of application deploys.
• Organizations already investing in policy-as-code for Terraform, CI/CD gates, or API gateways who want one engine instead of three.

Who should NOT use this

• Small teams with a handful of services and simple RBAC needs — OPA adds real operational and cognitive overhead (Rego has a learning curve) that isn't justified at small scale.
• Teams wanting a turnkey Kubernetes policy solution with minimal setup — Kubernetes-native alternatives with simpler syntax (see below) get you 80% of the value with far less Rego to write and maintain.
• Anyone expecting a managed SaaS experience out of the box — raw OPA is self-hosted and self-operated; you need Styra DAS or another wrapper for a managed control plane, dashboards, and policy distribution at scale.
• Teams that need real-time, high-throughput authorization with sub-millisecond latency at extreme scale without capacity planning — OPA's evaluation performance is generally fine, but it's not free, and Rego policy complexity can degrade eval time if not written carefully.

Alternatives

• Kyverno — Kubernetes-native policy engine using YAML instead of Rego; much lower learning curve if your only use case is K8s admission control.
• AWS Cedar — policy language purpose-built for fine-grained authorization, backed by AWS, if you're deep in that ecosystem.
• HashiCorp Sentinel — policy-as-code tightly integrated with Terraform/Vault/Consul if you're already in the HashiCorp stack and don't need cross-platform generality.

Pricing

OPA itself is fully open source (Apache-2.0) — no license cost, no feature gating. Commercial management/UI layers (e.g., Styra DAS) exist separately with their own pricing, but the core engine and Rego runtime are free to run anywhere.