Rego is a declarative, logic-based language evaluated by Open Policy Agent (OPA), a lightweight policy engine for distributed systems. It expresses decisions over JSON input rather than hard-coding them into protected applications. That makes it useful beyond authorization: the same approach can validate Kubernetes resources, restrict API inputs, enforce admission control, and govern CI/CD or container workflows. section 8.2 section 8.5.2
A Rego rule defines the conditions under which a decision is true. Policies commonly receive user-defined principal, action, resource, and context data through input. Rego does not impose types, schemas, or built-in authorization concepts for those elements: an action may be a string, while principals and resources may be arbitrary JSON objects. This supports rich, changing data but makes careful input design, explicit conditions, validation, and testing essential. section 8.2.3 section 8.2.4
Confidential-document access
This policy denies by default and allows access only when a document is confidential and the requester belongs to the owner’s department. The authorization decision is determined by conditions in the allow rule body. section 8.2.1
package acme.authz
import rego.v1
default allow := false
allow if {
input.resource.confidential == true
input.principal.department == input.resource.owner.department
}
The listing shows a package, the rego.v1 import, a default deny decision, and an allow rule evaluated against input data. section 8.2.1
This flexibility has an architectural tradeoff. Rego places principal, action, and resource constraints inside rule bodies rather than declaring policy scope structurally. A delete rule, for example, must explicitly test both input.action and group membership. Compared with Cedar’s structural scoping, this leaves policy authors responsible for managing scope and semantics and does not provide built-in filtering of policies by principal, action, or resource. section 8.2.2 section 8.5.2
Rego is particularly suited to policy decisions that need broad, data-driven context:
- Infrastructure enforcement across microservices, Kubernetes, APIs, CI/CD pipelines, and container deployments. section 8.2
- Runtime decisions using time, location, network conditions, request headers, or other supplied and external data. section 8.2.3
- Portable, testable policies kept independent from the applications they protect. section 8.2.4
Rego is strong where cloud-native infrastructure needs adaptable logic over varied data. Its logic-programming model can be difficult to learn, and policies can become hard to read or maintain. For access-control systems that need typed entities, explicit policy scope, or relationship-based sharing and delegation, a more authorization-specific approach may fit better. section 8.2.4 section 8.5.6
