DevOps Glossary

Open Policy Agent (OPA) is an open source policy engine that evaluates rules for access, configuration, deployments, and operational decisions. In practical terms, OPA lets you write policy once, then apply it consistently across APIs, Kubernetes, CI/CD pipelines, infrastructure as code, and cloud workflows.

What OPA does

Open Policy Agent separates policy decisions from application and platform code. Instead of hard-coding rules inside each service or script, systems ask OPA a question and receive a decision such as allow, deny, warn, or return a filtered result.

Common policy checks include:

• Can this user call this API endpoint?
• Can this Kubernetes workload run as privileged?
• Does this Terraform plan create public storage?
• Does this deployment include required labels, resource limits, or approved images?
• Can this service communicate with another service?

How OPA works

OPA evaluates structured input data against policies written in Rego, OPA’s policy language. The input is usually JSON-like data that describes a request, deployment, plan, or runtime context.

A typical flow looks like this:

1. A system sends input to OPA, such as a Kubernetes admission request or an API authorization request.
2. OPA evaluates that input against Rego policies and optional external data.
3. OPA returns a decision to the calling system.
4. The calling system enforces the decision, such as blocking a request or allowing a deployment.

OPA can run as a sidecar, a daemon, a library, or as part of a CI/CD job. The enforcement point depends on the platform using it. OPA makes the decision, but another system usually applies it.

Common use cases

• Kubernetes admission control: Block Pods that use privileged mode, missing resource limits, unapproved registries, or invalid labels.
• API authorization: Decide whether a user, service, or token can perform an action on a resource.
• Infrastructure as code checks: Validate Terraform, CloudFormation, or Kubernetes manifests before they reach production.
• CI/CD policy gates: Fail builds or deployments that violate release, security, or compliance rules.
• Service mesh and proxy authorization: Apply request-level decisions near traffic entry points, such as with Envoy integrations.

Key parts and related concepts

• Rego: The declarative language used to write OPA policies.
• Input: The request or configuration data that OPA evaluates.
• Data: Extra context used by policies, such as team ownership, allowed regions, risk levels, or user roles.
• Decision: The result returned by OPA, often a boolean or structured JSON response.
• Policy bundle: A packaged set of policies and data that can be distributed to OPA instances.

OPA and Kubernetes

In Kubernetes, OPA is often used through Gatekeeper, a Kubernetes admission controller built around OPA. Gatekeeper lets platform teams define constraints such as “all namespaces must have an owner label” or “containers must not run as root.”

OPA itself is the policy engine. Gatekeeper is a Kubernetes-specific integration that uses OPA to validate resources before they are admitted to the cluster.

OPA compared with nearby tools

• OPA vs Kubernetes RBAC: Kubernetes RBAC controls who can perform API actions, such as create Pods or update Deployments. OPA can inspect the content of the object being created, such as image name, security context, labels, and resource settings.
• OPA vs Gatekeeper: OPA is the general policy engine. Gatekeeper applies OPA policies to Kubernetes admission control.
• OPA vs Azure Policy: Azure Policy is a cloud governance service for Azure resources. OPA is a general-purpose policy engine that can run across many environments, including Kubernetes, CI/CD, APIs, and custom services.

Benefits

• Centralized policy logic: Teams can keep policy decisions outside application code and apply them across multiple systems.
• Consistent enforcement: The same rule can be used in CI, admission control, and runtime checks when the input format supports it.
• Version-controlled policies: Rego policies can live in Git, go through code review, and follow normal release workflows.
• Flexible decisions: OPA can return simple allow or deny results, or richer structured decisions for custom workflows.

Tradeoffs and limitations

• Rego has a learning curve: Engineers need time to understand its declarative model, testing patterns, and data structures.
• OPA does not enforce by itself: The calling system must respect and apply OPA’s decision.
• Input quality matters: Policies are only as useful as the data sent to OPA.
• Policy sprawl can happen: Without ownership, naming standards, and tests, policies can become hard to maintain.

Simple example

A platform team wants every Kubernetes Deployment in production to set CPU and memory limits. They write an OPA policy that checks incoming admission requests. If a container has no limits, OPA returns a deny decision with a message such as “containers must define CPU and memory limits.” Kubernetes then rejects the deployment before it reaches the cluster.

This gives developers fast feedback, keeps the rule consistent, and prevents misconfigured workloads from reaching production.