What is
OPA
?
Most platform initiatives fail the same way: they start too big, get funded like projects instead of products, build for too long without testing with users, and confuse renaming an infrastructure team with building a platform team. Instead, start small, learn fast and scale deliberately.
At a glance
Field | Details |
|---|---|
Primary use case | Unified policy-as-code decisions and enforcement across applications and infrastructure |
Deployment type | Self-hosted server, sidecar, host-level daemon, or embedded library |
Pricing model | Open source |
API compatibility | REST API, Envoy External Authorization API, Kubernetes admission API |
Supported integrations | Envoy, Kubernetes, OpenShift, Ansible Automation Platform, CI/CD pipelines, API gateways |
Source type | Open |
Cloud provider | Cloud Agnostic |
Required skills | Rego policy authoring, JSON data modeling, authorization concepts, REST API or SDK integration; Kubernetes admission configuration for Kubernetes use cases |
AEP branch | Tooling |
AEP category | Security Plane |
AEP subcategory | Policy Control |
Profile
Policy Control is the most specific AEP level for OPA. OPA is a general-purpose policy engine that separates policy from application logic, allowing policies to be managed centrally while applications and infrastructure request policy decisions.
OPA uses Rego, a declarative policy language, to evaluate input data against defined policies. Applications can integrate with OPA through SDKs or its REST API; the engine also provides native integration with the Envoy External Authorization API and can evaluate Kubernetes admission requests. Its policy use cases include applications, proxies, Kubernetes, CI/CD pipelines, API gateways, and AI tool-call controls.
OPA supports audit trails for policy decisions, which can be used for auditing, compliance, analysis, and debugging.
Focus
OPA serves security and platform teams that manage shared policies, as well as developer teams that apply or extend those policies. It addresses the need to make policy decisions consistently across applications and infrastructure without embedding policy rules in each application's business logic.
Teams can use it to make runtime authorization decisions, control which Kubernetes resources may be created, and apply rules to other requests, such as Envoy traffic or AI agent tool calls.
Background
OPA and Rego began at Styra in 2016 and were open-sourced through the Open Policy Agent GitHub organization. OPA is a Cloud Native Computing Foundation Graduated project. The supplied background research does not specify a funding history.
Features
Declarative policy authoring with Rego
Rego lets teams express policies separately from application logic, supporting shared policy management and team-specific extensions. OPA evaluates policies against input data, including JSON-formatted request context.
Runtime policy decisions through APIs and SDKs
Applications can request domain-specific decisions without implementing the policy rules themselves. OPA exposes a REST API and supports direct integration through SDKs; its Policy API includes CRUD endpoints for managing policy modules.
Envoy authorization integration
OPA can evaluate authorization policies for Envoy requests. Its native integration with the Envoy External Authorization API uses request attributes, such as HTTP method, path, and headers, as policy input.
Kubernetes admission policy enforcement
OPA can check whether proposed Kubernetes resources meet organizational rules. The Kubernetes API can send admission requests to OPA, where custom policies evaluate the request and can return denial messages.
Policy decisions across the stack
OPA applies policy controls to applications, proxies, Kubernetes, CI/CD pipelines, API gateways, and AI tool calls. For AI agents, policies can restrict which tools are callable and which parameters are permitted.
Decision audit trails
OPA generates audit trails for policy decisions, supporting auditing, compliance, and later analysis or debugging of decisions.
Pros and cons
Pros
A general-purpose policy engine supports policy decisions across application and infrastructure contexts, including applications, Envoy, Kubernetes, CI/CD pipelines, and API gateways.
Separating policy from application logic supports central management of shared policies while allowing developer teams to extend them within the policy system.
REST API, SDK, Envoy authorization, and Kubernetes admission integration provide multiple ways to connect policy evaluation to services and infrastructure.
Policy decision audit trails support compliance work and analysis or debugging.
Cons
A Reddit discussion reports that some users find Rego confusing and unnecessarily complicated. This is anecdotal feedback, but it points to the practical effort involved in authoring and understanding Rego policies.
FAQs
OPA FAQ
How does OPA evaluate policy decisions?
OPA evaluates input data against policies written in Rego, a declarative policy language. Applications can request decisions through OPA’s REST API or SDKs.
Which systems can OPA integrate with?
OPA supports integrations with Envoy, Kubernetes, OpenShift, Ansible Automation Platform, CI/CD pipelines, and API gateways.
What does OPA cost?
OPA has an Open source pricing model.
What skills are required to use OPA?
Required skills for OPA are: Rego policy authoring, JSON data modeling, authorization concepts, REST API or SDK integration; Kubernetes admission configuration for Kubernetes use cases.
How can OPA be deployed?
OPA can be deployed as a self-hosted server, sidecar, host-level daemon, or embedded library.
What is a limitation of OPA?
Some users report finding Rego confusing and unnecessarily complicated; this is anecdotal feedback.
