Open Policy Agent (OPA)

OPA uses Rego, a purpose-built, declarative query language for defining policies. Rego allows you to specify what the policy decision should be, not how to execute it. Policies are expressed as rules that define the content of documents.

• Logic-based: Inspired by Datalog, Rego extends it to support structured document models like JSON.
• Focus on Relationships: Enables sophisticated queries about relationships between users, resources, and actions.
• Example: A rule to allow access if the user's department matches the resource's owner: allow { input.user.department == input.resource.owner }

OPA implements a clear separation between the Policy Decision Point (PDP) and the Policy Enforcement Point (PEP). The service (PEP) queries OPA (PDP) for decisions, passing structured JSON data (input).

• Standardized Interface: Services call OPA's REST API or use embedded Go libraries with a simple query: data.<policy path>.
• Unified Control: Different services (APIs, Kubernetes, CI/CD pipelines) can query the same OPA instance, ensuring policy consistency.
• Architecture: This decoupling allows policy logic to be updated, versioned, and audited independently of application code.

OPA policies make decisions based on rich, structured context bundled into the input document. This goes beyond simple user/action/resource tuples.

• Dynamic Input: The input can include user attributes, resource metadata, network information, time of day, and other relevant data.
• Real-time Evaluation: Policies can query external data (loaded into OPA) during evaluation, allowing decisions based on live system state.
• Use Case: A policy can deny a deployment if the requesting user is not in the 'on-call' roster and it's outside business hours, using context from multiple sources.

OPA is not a standalone platform but an engine designed for integration. It has a rich ecosystem of tools and plugins for major platforms.

• Kubernetes: The OPA Gatekeeper project provides admission control for Kubernetes, enforcing policies on resource creation (e.g., 'all Pods must have resource limits').
• API Gateways & Service Meshes: Integrations with Envoy (via External Authorization), Apache APISIX, Kong, and Istio for API-level authorization.
• CI/CD & Infrastructure as Code: Conftest uses OPA to test configuration files (Terraform, Kubernetes YAML, Dockerfiles) for policy compliance before deployment.
• Developer Tooling: VS Code extensions, REPL environments, and test frameworks are available for Rego development.

OPA supports a robust development lifecycle for policies, treating them as code that can be tested, versioned, and distributed.

• Unit Testing: Rego includes a test framework. You can write tests that verify policies produce expected decisions for given inputs: test_allow { allow with input as {...} }
• Bundles: Policies and external data files can be packaged into tar.gz bundles. OPA instances can be configured to periodically download bundles from remote HTTP servers, enabling centralized policy distribution.
• Versioning & Rollback: Bundles facilitate version control and safe rollbacks of policy across an entire fleet of OPA instances.

OPA is engineered for low-latency decision-making, which is critical for authorization in request paths (e.g., API gateways, service meshes).

• Partial Evaluation: OPA can perform partial evaluation when some input is known ahead of time. This pre-compiles policies, reducing runtime evaluation to a simple document lookup.
• Indexing & Caching: The engine automatically indexes rules and caches intermediate results during query evaluation to maximize performance.
• Deterministic Output: For a given policy and input, OPA will always produce the same decision, which is essential for debugging and auditability.

A Policy Decision Point (PDP) is the core logic component in a policy-based architecture that evaluates incoming access requests against a set of policies to render an authorization decision (allow/deny).

• OPA as a PDP: OPA serves as a standalone, general-purpose PDP. It is decoupled from the application, receiving a JSON-structured query (the input), evaluating it against Rego policies, and returning a decision.
• Architectural Role: Sits centrally in the authorization flow. The Policy Enforcement Point (PEP) in your service calls the PDP (OPA) for each decision.
• Key Characteristic: A pure PDP like OPA is stateless for decision-making; it evaluates based on the provided input and bundled policy data, promoting scalability and consistency.

A Policy Enforcement Point (PEP) is the component that intercepts an access request, consults a Policy Decision Point (PDP) for a decision, and enforces that decision by allowing or denying the request.

• Relationship with OPA: The PEP is the integration point within your application (e.g., a middleware function in an API gateway or microservice). It is responsible for:
  • Constructing the query input (user, action, resource, context).
  • Calling the OPA PDP via its API.
  • Enforcing OPA's allow/deny decision.
• Separation of Concerns: OPA provides the decision logic (PDP), but the PEP must be implemented in the application's runtime to call OPA and act on its output.

Attribute-Based Access Control (ABAC) is an authorization model where access decisions are based on attributes (characteristics) of the user, resource, action, and environment, evaluated against policies.

• OPA's Natural Fit: OPA is exceptionally well-suited for implementing ABAC. The query input to OPA is a JSON object containing all relevant attributes (e.g., user.department, resource.sensitivity, action, environment.time).
• Flexibility: Policies written in Rego can express complex Boolean logic across any combination of these attributes (e.g., allow if user.role == "manager" AND resource.owner == user.id OR environment.location == "HQ").
• Contrast with RBAC: While OPA can enforce Role-Based Access Control (RBAC), its power lies in going beyond static roles to evaluate dynamic, multi-dimensional attributes for fine-grained control.

OPA can make policy decisions using external data that is not part of the initial query input, enabling decisions based on real-time context from other systems.

• Data Bundles: OPA can periodically download signed bundles of policy and data (JSON files) from remote HTTP servers. This is the primary method for loading large, semi-static datasets (e.g., user-group mappings, IP allowlists) into OPA's data namespace.
• Dynamic Data via http.send: Within a Rego policy, the built-in function http.send can perform outbound HTTP requests to fetch fresh data at evaluation time (e.g., call a user directory service). Use with caution due to latency and failure implications.
• Architectural Impact: This capability allows OPA to act as a unified PDP that integrates context from multiple external sources (LDAP, CMDB, threat feeds) without burdening the client application.