Open Policy Agent (OPA) and Gatekeeper Cheat Sheet

Updated 2026-05-22

Next Topic: Pod Security Standards and Kubernetes Security Hardening Cheat Sheet

Open Policy Agent (OPA) is a general-purpose, CNCF-graduated policy engine that decouples policy decision-making from application and infrastructure code, using its declarative language Rego to evaluate structured data such as API requests, Kubernetes manifests, and IaC configurations. Gatekeeper extends OPA into a Kubernetes-native admission controller, providing CRD-based policy management via ConstraintTemplates and Constraints. The core mental model to internalize is that OPA never enforces by itself — it only decides; enforcement always lives in the caller (webhook, sidecar, CI step) that acts on OPA's response.

What This Cheat Sheet Covers

This topic spans 23 focused tables and 216 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Rego Language FundamentalsTable 2: Rego Built-in FunctionsTable 3: OPA Decision API and REST APITable 4: OPA Partial Evaluation and Data FilteringTable 5: OPA Bundles and Policy DistributionTable 6: OPA Decision Logs and ObservabilityTable 7: Gatekeeper Architecture and Core ComponentsTable 8: Gatekeeper Enforcement ModesTable 9: Gatekeeper MutationTable 10: Gatekeeper Data Sync for Referential PoliciesTable 11: Common Gatekeeper Library ConstraintsTable 12: Gatekeeper gator CLITable 13: OPA Policy Testing (opa test)Table 14: Rego Performance OptimizationTable 15: OPA Envoy Integration (Ext Authz)Table 16: conftest for IaC and CI/CD ScanningTable 17: OPA vs Kyverno Trade-offsTable 18: GitOps for Policy DeliveryTable 19: Multi-Tenant Policy PatternsTable 20: Rego Common Pitfalls and GotchasTable 21: OPA v1 and Rego v1 SyntaxTable 22: Regal — The Rego LinterTable 23: OPA External Data Patterns

Table 1: Rego Language Fundamentals

Rego is a declarative, Datalog-inspired query language purpose-built for policy evaluation over JSON/YAML documents. Understanding how Rego evaluates rules — as logical assertions rather than imperative instructions — is the foundation for writing correct policies across all OPA use cases.

Concept	Example	Description
package declaration	`package authz`	• Namespaces rules • the package path determines the OPA data document path (e.g., `data.authz`).
rule definition (complete)	`allow if {` `input.method == "GET"` `}`	• Complete rule with a single value • in Rego v1 (OPA 1.0+) the `if` keyword is mandatory before the rule body
default rule	`default allow := false`	• Provides a fallback value when no other rule matches • prevents undefined decisions, which differ from `false`.
input document	`input.user.role == "admin"`	• The JSON object passed to OPA at query time • represents the request, event, or resource being evaluated
data document	`data.roles["admin"]`	OPA's in-memory store for base documents (static JSON/YAML loaded via API, bundles, or Gatekeeper sync).
assignment operator `:=`	`x := 42`	• Unification with explicit assignment • preferred over bare `=` for readability in Rego v1.
comparison `==`	`input.count == 5`	• Strict equality check • unlike `:=`, does not bind variables
unification `=`	`x = 42`	• Simultaneously binds and tests • evaluates to `undefined` if unification fails, which can be a gotcha.
negation `not`	`not input.privileged`	• Negation-as-failure: true when the expression under `not` is undefined or false • cannot bind new variables
`some` keyword	`some i; input.users[i].role == "admin"`	• Declares a local variable for iteration • makes the variable's scope explicit and prevents shadowing
`every` keyword	`every user in input.users {` `user.active == true` `}`	• Universally quantifies over a collection • rule body must be true for every element or the expression fails
`in` operator	`"admin" in input.roles`	• Membership test • also used with `some` for explicit iteration over collections

Table 1: Rego Language Fundamentals

Concept	Example	Description
package declaration	`package authz`	• Namespaces rules • the package path determines the OPA data document path (e.g., `data.authz`).
rule definition (complete)	`allow if {` `input.method == "GET"` `}`	• Complete rule with a single value • in Rego v1 (OPA 1.0+) the `if` keyword is mandatory before the rule body
default rule	`default allow := false`	• Provides a fallback value when no other rule matches • prevents undefined decisions, which differ from `false`.
input document	`input.user.role == "admin"`	• The JSON object passed to OPA at query time • represents the request, event, or resource being evaluated
data document	`data.roles["admin"]`	OPA's in-memory store for base documents (static JSON/YAML loaded via API, bundles, or Gatekeeper sync).
assignment operator `:=`	`x := 42`	• Unification with explicit assignment • preferred over bare `=` for readability in Rego v1.
comparison `==`	`input.count == 5`	• Strict equality check • unlike `:=`, does not bind variables
unification `=`	`x = 42`	• Simultaneously binds and tests • evaluates to `undefined` if unification fails, which can be a gotcha.
negation `not`	`not input.privileged`	• Negation-as-failure: true when the expression under `not` is undefined or false • cannot bind new variables
`some` keyword	`some i; input.users[i].role == "admin"`	• Declares a local variable for iteration • makes the variable's scope explicit and prevents shadowing
`every` keyword	`every user in input.users {` `user.active == true` `}`	• Universally quantifies over a collection • rule body must be true for every element or the expression fails
`in` operator	`"admin" in input.roles`	• Membership test • also used with `some` for explicit iteration over collections