Open Policy Agent (OPA): Centralized Policy as Code

WHY IT EXISTS As systems grow, enforcing consistent rules for security, compliance, and operations becomes chaotic. Policies get scattered across different services, written in different languages, and are hard to audit or update. OPA was created to solve this by providing a single, unified way to declare and enforce policy across the entire tech stack.

THE MENTAL MODEL OPA acts as a centralized policy decision service that your application offloads work to. The flow is: 1. Your service gathers relevant data (like a user request or a Kubernetes object) into a JSON document. 2. It sends this JSON to the OPA engine with a query. 3. OPA evaluates the JSON against policies written in its declarative language, Rego. 4. OPA returns a decision, which can be a simple boolean or a complex JSON object, back to your service. Your service then enforces that decision.

HOW IT WORKS OPA runs as a sidecar, a daemon, or a library. You write policies in Rego, a language designed for querying complex data structures. These policies are loaded into the OPA engine. When your application needs a decision, it makes an API call to OPA, providing the input JSON. OPA evaluates the query against its loaded policies and any additional data it has. The result of the evaluation is sent back as the API response. This decouples the policy logic from the application lifecycle, allowing you to update policies without redeploying your app.

WHEN TO USE IT Use OPA to centralize policy enforcement in distributed systems. It excels in scenarios like: Kubernetes admission control (e.g., 'all pods must have resource limits'), CI/CD pipeline validation (e.g., 'no dependencies with critical vulnerabilities'), API authorization in gateways (e.g., 'user X can access resource Y'), and infrastructure-as-code validation (e.g., 'all S3 buckets must have encryption enabled').

WHEN NOT TO USE IT OPA is for policy decision-making, not enforcement. Your service is still responsible for actually blocking the request or performing the action based on OPA's decision. It is not a database or a secret management tool. If your policy logic is extremely simple and confined to a single service, integrating OPA might be overkill.

ONE CANONICAL EXAMPLE A Kubernetes Admission Controller intercepts a request to create a new Pod. It sends the Pod's JSON manifest to OPA. The OPA policy, written in Rego, inspects the spec.containers[*].image field. If any image name does not start with 'our-trusted-registry.io/', OPA returns a {"allowed": false, "reason": "Image is from an untrusted registry"} response. The admission controller then rejects the Pod creation, enforcing the policy.