Open Policy Agent (OPA)

Open Policy Agent (OPA) is a general-purpose, CNCF-graduated policy engine that decouples policy decisions from application code. Services write rules in Rego, OPA’s declarative policy language, and query OPA at decision time instead of hardcoding authorization logic; OPA evaluates the rules against the data it’s given and returns allow/deny (or arbitrarily structured) decisions.

OPA ships as a standalone binary you run as a CLI (opa eval, opa test) or as a long-running server (opa run —server) queried over a REST API, and it embeds directly into Go services via the rego package for in-process evaluation without a network hop. It’s widely used for Kubernetes admission control, API authorization, Terraform plan validation, and CI/CD policy gates.

What You Get

• A standalone CLI (opa eval, opa run, opa test, opa fmt) for authoring, testing, and running Rego policies locally
• A server mode (opa run —server) exposing a REST API for centralized policy decisions
• A Go embedding API (the rego package) for compiling and evaluating policies in-process without a network call
• A pluggable runtime (bundle downloads, decision logging, status reporting, discovery) for production deployments
• A WebAssembly compilation target for running compiled policies outside the OPA runtime
• An interactive REPL and the hosted Rego Playground for exploring and sharing policies

Common Use Cases

• Kubernetes admission control — validating or mutating resources before they’re persisted
• API authorization — services querying OPA for allow/deny decisions on incoming requests
• Infrastructure-as-code policy gates — validating Terraform plans before apply
• CI/CD policy enforcement — checking build artifacts, container images, or manifests against organizational rules
• Embedding fine-grained authorization directly into a Go service via the rego package

Under The Hood

Architecture OPA is organized as a layered system: a public compatibility layer at the module root (rego, ast, bundle, storage, loader, plugins) thinly re-exports the actual implementation living under v1/ (v1/rego, v1/ast, v1/topdown, v1/plugins, v1/server, v1/storage) — a versioning strategy that lets the Go API evolve without import-path churn for consumers pinned to the root packages. The CLI (cmd/, wired from main.go via cmd.RootCommand, a Cobra command tree) is a thin shell over the same library code used for embedding: eval.go, run.go, build.go, and exec.go each drive v1/rego.New()/topdown for one operation. Rego source is compiled by v1/ast and v1/compile into an intermediate representation (v1/ir) that v1/topdown evaluates as a tree-walking interpreter over in-memory storage (v1/storage, with a badger/v4-backed on-disk option for larger datasets), while v1/plugins supplies the pluggable pieces — bundle downloader, decision logging, status reporting, discovery — that opa run —server wires together for production deployments. Changing the core rego.Rego evaluation abstraction would ripple through the CLI commands, the server, the SDK, and the WASM compiler target, since all of them build on the same PrepareForEval/Eval surface.

Tech Stack Pure Go (go.mod targets go 1.26.0) with almost no external dependency for the evaluation core itself; cmd/ leans on spf13/cobra, spf13/pflag, and spf13/viper for CLI and configuration, prometheus/client_golang plus the go.opentelemetry.io/otel stack for metrics and tracing, dgraph-io/badger/v4 as the embedded key-value store backing on-disk storage, lestrrat-go/jwx/v3 for JWT-based token-verification builtins, tetratelabs/wazero as a pure-Go WebAssembly runtime used both to execute compiled Rego-to-WASM policies and to compile them, reeflective/readline for the REPL, and huandu/go-sqlbuilder plus santhosh-tekuri/jsonschema/v6 supporting SQL- and JSON-Schema-aware builtins. Build tooling is Makefile-driven with go:generate steps for a PEG parser generator and JSON-schema/version-index/capabilities generators, and the project ships as a static Go binary (Docker images) as well as a WASM SDK bundle.

Code Quality Nearly 400 _test.go files span the tree, heaviest in v1/topdown, v1/ast, v1/rego, and cmd/, mixing table-driven Go tests with the project’s own dogfooded Rego test fixtures evaluated via opa test. CI runs a wide set of GitHub Actions workflows covering pull-request checks, nightly builds, benchmarks, CodeQL analysis, an OpenSSF Scorecard, and a fuzz target, and .golangci.yaml enables a broad linter set (errcheck, govet, staticcheck, gocritic, revive, prealloc, misspell, modernize) enforced through make check. Error handling is idiomatic Go — explicit returns wrapped with fmt.Errorf/%w and a handful of typed sentinel errors — with no swallowed errors observed in the sampled core evaluation code, and naming follows standard Go exported/unexported conventions throughout.

API Design The rego.New(…).PrepareForEval(ctx) / preparedQuery.Eval(ctx, rego.EvalInput(x)) pattern is a deliberately two-phase API — compile once, evaluate many times with different inputs — which is the ergonomic core of embedding OPA in a hot request path without re-parsing or re-compiling policy on every call. Options are supplied as functional EvalOption/Option values (EvalInput, EvalMetrics, EvalTransaction, EvalQueryTracer) rather than a single large struct, keeping call sites readable while remaining extensible, and the higher-level sdk package wraps this further into a single OPA object that handles bundle downloading, discovery, and decision logging for services that don’t need low-level control. Documentation is unusually strong for an open-source project: a dedicated docs site with well over a thousand pages and a live Rego Playground for interactive exploration, and the root-level rego package intentionally forwards to v1/rego with doc comments preserved so pkg.go.dev usage isn’t degraded by the versioning shim.