What is Open Policy Agent (OPA) and How Does Rego Work?
Learn what Open Policy Agent is, how Rego rules evaluate structured input, and how OPA powers Kubernetes admission control.
Expected Interview Answer
Open Policy Agent (OPA) is a general-purpose, open-source policy engine that decouples policy decision-making from application logic — services send it structured JSON input, OPA evaluates that input against declarative rules written in the Rego language, and returns an allow/deny decision that the calling service (a Kubernetes API server, an API gateway, a CI pipeline) enforces.
Rego is a declarative, Datalog-derived query language: a policy is a set of rules that each produce a value (often a boolean or a set of denial messages) when their conditions match against the input document and any reference data. Because OPA is decoupled from the systems it protects, the same engine can enforce Kubernetes admission control (rejecting a Pod that requests privileged containers), API authorization (deciding if a JWT-bearing request may call an endpoint), and Terraform plan validation (denying a plan that opens a security group to 0.0.0.0/0), all using the same policy language and the same evaluation model. OPA is commonly deployed as a sidecar or daemon that the enforcing service calls over a fast local HTTP or gRPC API, and policies can be bundled, versioned, and hot-reloaded without redeploying the services that consume decisions. The Gatekeeper project builds Kubernetes-native CRDs (ConstraintTemplates and Constraints) on top of OPA specifically for admission control use cases.
- Decouples authorization/policy logic from application code
- One engine and language enforces policy across Kubernetes, APIs, and IaC
- Policies can be updated and hot-reloaded independently of services
- Rego produces precise denial messages, not just pass/fail
AI Mentor Explanation
OPA is like a centralized third-umpire review system that every ground in a league plugs into, sending the exact same replay footage format and getting back the exact same style of ruling, rather than each stadium inventing its own review process. The rulebook the third umpire applies — Rego — is a shared, declarative set of conditions like "if front foot is over the line, no-ball" that produces a specific ruling, not just a bare yes or no. Because the review system is separate from any single ground’s staff, upgrading the lbw rule updates every ground simultaneously without retraining every local umpire. A bowling-action check and a boundary-catch check both run through the identical review engine.
Step-by-Step Explanation
Step 1
Send structured input
The enforcing service (K8s API server, gateway, CI job) sends a JSON document describing the request to OPA.
Step 2
Evaluate Rego rules
OPA matches the input against declarative Rego rules and any loaded reference data.
Step 3
Return a decision
OPA returns allow/deny (or a set of violation messages) as a JSON response.
Step 4
Enforce and iterate
The calling service enforces the decision; policies can be updated and hot-reloaded independently of the service.
What Interviewer Expects
- Understanding that OPA decouples policy decisions from application/service logic
- Knowledge that Rego is a declarative, Datalog-derived rule language
- Awareness of concrete use cases: Kubernetes admission control, API authz, IaC validation
- Familiarity with the Gatekeeper project as the K8s-native layer on top of OPA
Common Mistakes
- Describing OPA as Kubernetes-only, ignoring its general-purpose nature
- Confusing Rego with an imperative scripting language
- Not knowing OPA returns structured decisions, not just booleans
- Overlooking that policies can be hot-reloaded without redeploying services
Best Answer (HR Friendly)
“Open Policy Agent is a tool that centralizes decision-making for rules like 'who can access this API' or 'what Kubernetes settings are allowed,' separate from the actual application code. We write the rules once in its policy language, Rego, and any system — Kubernetes, an API gateway, our CI pipeline — can ask it for a yes-or-no decision, which keeps our rules consistent and easy to update in one place.”
Code Example
package kubernetes.admission
deny[msg] {
input.request.kind.kind == "Pod"
container := input.request.object.spec.containers[_]
container.securityContext.privileged == true
msg := sprintf("Privileged container not allowed: %s", [container.name])
}Follow-up Questions
- How does OPA integrate with Kubernetes admission control via Gatekeeper?
- What is the performance overhead of calling OPA on every API request?
- How would you unit test a Rego policy?
- How does OPA handle policy bundle distribution and hot-reloading?
MCQ Practice
1. What is the primary role of Open Policy Agent?
OPA evaluates structured input against declarative policies and returns decisions, independent of the systems that enforce them.
2. What language are OPA policies written in?
Rego is the declarative, Datalog-derived language used to author OPA policies.
3. What Kubernetes-native project builds admission-control CRDs on top of OPA?
Gatekeeper provides ConstraintTemplate and Constraint CRDs that wrap OPA for native Kubernetes admission control.
Flash Cards
What is OPA? — A general-purpose, open-source policy engine that decouples policy decisions from application logic.
What language does OPA use? — Rego, a declarative, Datalog-derived query language.
Name a common OPA use case. — Kubernetes admission control, API authorization, or Terraform plan validation.
What project adds K8s-native CRDs on top of OPA? — Gatekeeper, via ConstraintTemplate and Constraint resources.