Open Policy Agent (OPA)

OPA separates the policy decision point (PDP) from the policy enforcement point (PEP). Instead of embedding authorization logic directly into microservices, APIs, or Kubernetes admission controllers, applications query OPA via a simple REST API. This decoupling allows security and compliance teams to update policies without modifying application code, recompiling, or redeploying services. The architecture follows a clear query-response pattern: the application sends structured JSON data (the input document) to OPA, and OPA returns an allow/deny decision along with any structured response data.

Policies are expressed in Rego, a declarative, domain-specific language inspired by Datalog. Rego queries structured JSON documents and returns decisions based on rules that evaluate to true or false. Key characteristics include:

• Declarative syntax: You describe what the policy outcome should be, not how to compute it
• Set-based logic: Rules iterate implicitly over all possible variable bindings
• Incremental definitions: Rules with the same name are logically OR'd together
• Built-in functions: Includes operations for string manipulation, JWT verification, HTTP requests, and cryptographic checks

Example: allow { input.user.role == "admin" } grants access when the user role attribute equals "admin".

OPA provides a single, unified policy framework that operates across the entire cloud-native stack. The same Rego policies and OPA binary can enforce rules for:

• Kubernetes admission control: Validating and mutating webhook decisions for pod security, resource limits, and image provenance
• API authorization: Enforcing attribute-based access control (ABAC) at the gateway or middleware layer
• Infrastructure as Code: Scanning Terraform plans and CloudFormation templates for compliance violations before provisioning
• SSH and sudo: Controlling Linux host access via the opa eval command-line interface
• Data filtering: Returning only the subset of data a user is authorized to see from a database query

OPA is designed as a stateless sidecar or daemon that evaluates policies in-memory with sub-millisecond latency. It does not maintain user sessions, transaction logs, or persistent state between queries. All context required for a decision must be supplied in the input document or fetched at evaluation time using the http.send built-in. This stateless design enables:

• Horizontal scaling: Deploy multiple OPA instances behind a load balancer without coordination
• High availability: No single point of failure; any instance can serve any query
• Embedded deployment: Compile OPA as a Go library directly into your application for zero-network-latency decisions
• Deterministic evaluation: Given identical input and data documents, OPA always produces identical output

OPA downloads policy bundles and data documents from remote HTTP servers, enabling centralized policy distribution. A bundle is a gzipped tarball containing Rego files and JSON data files that OPA fetches, verifies, and activates atomically. Key features include:

• Signature verification: Bundles can be signed with HMAC or ECDSA keys; OPA verifies signatures before activation
• Delta bundles: Only changed files are transmitted, reducing bandwidth for frequent policy updates
• Status reporting: OPA can push decision logs and telemetry to a remote service for auditing and monitoring
• Discovery configuration: A bootstrap configuration tells OPA where to find bundles, enabling dynamic reconfiguration without restarting the agent

OPA integrates with the broader cloud-native ecosystem through multiple interfaces:

• Kubernetes: Used as a ValidatingAdmissionWebhook and MutatingAdmissionWebhook; projects like Gatekeeper and Kyverno build on OPA
• Envoy Proxy: OPA exposes an External Authorization gRPC API compatible with Envoy's ext_authz filter for service mesh authorization
• Terraform: The terraform plan output can be evaluated against Rego policies using the OPA CLI or Conftest
• CI/CD Pipelines: Policy checks can gate deployments by evaluating infrastructure manifests before apply
• SQL and Kafka: OPA can filter query results or broker messages based on policy decisions, ensuring data-level authorization

OPA acts as a ValidatingAdmissionWebhook to enforce cluster-wide policies on every API request before resources are persisted to etcd.

• Pod Security: Require non-root users, deny privileged containers, enforce read-only root filesystems
• Resource Limits: Mandate CPU/memory requests and limits for all workloads
• Image Provenance: Restrict registries to trusted sources and enforce image digest pinning
• Ingress Rules: Validate hostnames, TLS configurations, and path routing conventions

OPA evaluates Rego policies against the AdmissionReview object, returning allow/deny decisions with detailed violation messages in milliseconds.

OPA is deployed as a sidecar or external service alongside API gateways like Envoy, Kong, or Traefik to externalize fine-grained authorization.

• JWT Validation: Verify token signatures, expiry, issuer, and audience claims
• Path-Based Access: Enforce role-based permissions on specific REST endpoints and HTTP methods
• Rate Limiting Logic: Evaluate complex quota rules based on user tier, IP, or API key attributes
• Data Filtering: Return row-level or column-level access decisions for multi-tenant databases

The gateway queries OPA via its REST API or gRPC, passing the HTTP request context as structured JSON input for policy evaluation.

OPA evaluates Terraform plans, CloudFormation templates, and Pulumi programs before provisioning to prevent misconfigurations from reaching production.

• Compliance Guardrails: Block public S3 buckets, open security groups, unencrypted RDS instances
• Cost Controls: Deny instance types above a specified size or regions outside approved boundaries
• Tagging Standards: Require mandatory tags for cost allocation, ownership, and environment classification
• IAM Least Privilege: Reject overly permissive policies with wildcard actions or resources

Integration occurs in CI/CD pipelines using tools like Conftest or direct OPA CLI evaluation against structured plan outputs.

OPA integrates with Envoy through its External Authorization API to enforce fine-grained, zero-trust policies at the service-to-service communication layer.

• mTLS Enforcement: Require valid SPIFFE identities for all inter-service calls
• Service Graph Policies: Define which services can communicate based on namespace, labels, or environment
• Request-Level Controls: Allow or deny based on HTTP headers, path prefixes, or request methods
• Dynamic Policy Updates: Push policy changes without restarting proxies or application instances

Each Envoy proxy calls OPA for every request, enabling attribute-based access control with full context from the mesh.

OPA is embedded as a Go library or called via its REST API to centralize authorization logic across microservices written in any language.

• Document-Level Permissions: Evaluate whether a user can read, edit, or delete a specific record based on ownership and role
• Feature Flags: Dynamically enable or disable features per user, tenant, or deployment stage
• Multi-Tenancy Isolation: Enforce tenant-scoped queries and prevent cross-tenant data access
• Workflow Approvals: Gate multi-step business processes on role hierarchies and spending thresholds

Application code sends a structured JSON input containing the subject, action, and resource attributes, receiving a simple allow/deny decision.

OPA enforces data access and transformation policies within Kafka, Spark, and dbt pipelines to ensure compliance with data governance frameworks.

• Column-Level Masking: Redact PII fields based on user clearance before data leaves the pipeline
• Schema Validation: Reject events that violate expected schemas or contain malformed fields
• Retention Policies: Enforce automated deletion or archival rules based on data classification tags
• Cross-Region Controls: Prevent data movement between geographic boundaries for sovereignty compliance

OPA evaluates policies at stream ingestion points and batch job boundaries, acting as a centralized policy decision point for the data platform.

The Secure Production Identity Framework for Everyone is a set of open-source standards for securely identifying software systems. It provides a universal identity control plane for distributed systems, issuing a cryptographically verifiable identity to every workload in the form of a SPIFFE Verifiable Identity Document (SVID) . OPA integrates with SPIFFE to make policy decisions based on the verified identity of the calling service, not just its IP address.

The SPIFFE Runtime Environment is the production-ready reference implementation of the SPIFFE standards. It acts as a node agent that attests to the identity of workloads and issues them short-lived X.509 or JWT SVIDs. SPIRE solves the Secret Zero Problem by using a hardware-based root of trust to bootstrap identity, enabling OPA to enforce policies like 'only a verified production frontend service can access the billing database.'