DevOps Dictionary
Open Policy Agent (OPA)
Open Policy Agent (OPA) is an open source policy engine that evaluates rules against data, requests, and configurations. Teams use OPA to make consistent decisions about authorization, security, compliance, and operational controls across applications, Kubernetes, CI/CD pipelines, and cloud infrastructure.
What OPA does
OPA separates policy decisions from application or platform code. Instead of hard-coding rules into each service, you write policies in one place and ask OPA whether a request, deployment, or configuration should be allowed.
OPA can answer questions such as:
- Can this user access this API endpoint?
- Does this Kubernetes deployment use an approved container registry?
- Is this Terraform plan creating a public storage bucket?
- Does this CI/CD pipeline meet required security checks before release?
How OPA works
OPA receives structured input, usually JSON, and evaluates it against policies written in Rego, OPA’s policy language. It then returns a decision, such as allow, deny, or a more detailed response with reasons and metadata.
A typical OPA flow looks like this:
- A system sends OPA input data, such as a user request or resource configuration.
- OPA evaluates that input against Rego policies.
- OPA returns a decision to the calling system.
- The calling system enforces the result, such as blocking a request or rejecting a deployment.
OPA can run as a sidecar, a host-level daemon, a library, or part of another tool. For Kubernetes admission control, many teams use Gatekeeper OPA to enforce policies before resources are created or changed in a cluster.
Common use cases
- API authorization: Decide whether a user, service, or role can perform an action on a resource.
- Kubernetes policy enforcement: Block workloads that miss labels, run as root, use privileged containers, or pull images from unapproved registries.
- Infrastructure as code checks: Validate Terraform, CloudFormation, or Kubernetes manifests before changes reach production.
- CI/CD governance: Require tests, approvals, vulnerability scans, or deployment conditions before a release proceeds.
- Cloud configuration controls: Check whether cloud resources follow internal security and compliance rules.
Key parts of OPA
- Rego: The declarative policy language used to define rules and decisions.
- Input: The request or configuration data OPA evaluates, usually represented as JSON.
- Data: External context used by policies, such as user roles, approved regions, allowed images, or exception lists.
- Decision: The result OPA returns to the caller, often allow or deny, but it can include structured details.
- Bundles: Packaged policy and data files that can be distributed to OPA instances.
Example
A platform team wants to prevent Kubernetes workloads from running as privileged containers. They write a Rego policy that checks incoming pod specs. When a developer submits a deployment, the Kubernetes admission controller sends the resource to OPA. If the pod sets privileged: true, OPA returns a deny decision and the deployment is rejected before it reaches the cluster.
Benefits and tradeoffs
OPA helps teams standardize policy decisions across many systems. It can reduce duplicated authorization logic, make policy reviews easier, and give security teams a consistent way to define controls.
There are tradeoffs. Rego has a learning curve, and policy design needs careful testing. If policies are too broad, they can block valid work. If they are too loose, they may miss important risks. OPA also returns decisions rather than enforcing every action by itself, so the integrating system must apply the result correctly.
OPA compared with nearby tools
OPA is a general-purpose policy engine. It can support many environments, including apps, Kubernetes, CI/CD, and infrastructure workflows. By comparison, Azure Policy focuses on governing Azure resources, such as requiring tags, restricting regions, or auditing resource settings inside Azure subscriptions.
OPA also differs from an identity provider. An identity provider authenticates who someone is. OPA decides whether that identity, combined with context and policy, should be allowed to take a specific action.