Getting Started with OPA

This guide orients you to Open Policy Agent (OPA) for authorization. EnforceAuth builds on OPA bundles — we teach the journey here; the OPA project owns language semantics.

Pick OSS OPA or EOPA before you install a container image or write your first package line.

Running OPA on Kubernetes? See Kubernetes Control Center — application sidecars vs cluster admission governance, plus PDP Monitoring.

Choose your PDP first — OSS OPA or EOPA?

Before Rego tutorials and opa test, decide which Policy Decision Point (PDP) will evaluate your policies at runtime:

	OSS OPA (default)	Enterprise OPA (EOPA)
Who it's for	First-time Policy as Code teams, standard RBAC/ABAC, small–medium fleets	Regulated log masking, very large fleets, bundle partitioning
License	Apache 2.0 — CNCF OPA	Apache 2.0 — CNCF EOPA subproject
Rego & EnforceAuth bundles	Same	Same

You are not choosing EnforceAuth instead of OPA. EnforceAuth is the control plane (Git → test → bundle → deploy). OPA or EOPA is the engine that loads the bundle and answers allow/deny for your application.

Default for new teams

Start with OSS OPA (openpolicyagent/opa). It is CNCF graduated, widely documented, and fully supported by EnforceAuth. You can switch to EOPA later without rewriting Rego — usually a container image and config change.

Read the full decision guide — comparison table, decision tree, and when EOPA-specific features matter:

→ OPA vs Enterprise OPA (EOPA)

That page is written for greenfield adoption, not only for teams migrating from another vendor. Sidecar vs centralized PDP is a separate decision — see Deployment patterns after you pick OPA or EOPA.

Also migrating from Styra DAS™ or an existing EOPA fleet?

That is a valid path, but not the default story. See OPA vs EOPA § migration and Migration from Styra DAS™ / EOPA when it applies to you.

Official OPA language reference

Tutorials and Rego semantics: openpolicyagent.org/docs

What OPA does

OPA is a general-purpose policy engine. Your service (the Policy Enforcement Point, or PEP) sends input JSON; OPA evaluates Rego policies and returns allow/deny (and optional metadata).

package example.authz

default allow := false

allow if {
    input.user.role == "admin"
}

Local workflow

1. Install OPA: installation docs
2. Write policy in policy.rego
3. Test with opa test and opa eval
4. Build a bundle for deployment

Use OSS OPA locally even if you later run EOPA in production — the Rego and bundle format are the same.

OPA with EnforceAuth

EnforceAuth manages bundle build, signing, multi-environment promotion, and decision log collection. Your PDP (OPA or EOPA) pulls bundles from the destination you configure in the console.

End-to-end setup: 15-minute quickstart. Runtime config: PDP integration (bundle polling, decision log plugins).

Next

1. Kubernetes Control Center — app sidecars vs cluster admission + PDP Monitoring
2. OPA vs EOPA — confirm your PDP choice (if you skipped it above)
3. Rego essentials
4. Rego patterns
5. Deployment patterns
6. Application integration
7. PDP integration
8. OPA best practices
9. OPA Community Pulse