Open Policy Agent for MSPs: admission, API authorization and CI gates

Open Policy Agent (OPA) is best known as the engine behind Kubernetes admission control, but the core project has nothing Kubernetes-specific about it. This guide is for MSPs and platform teams that want to use OPA as a general-purpose policy engine — for API authorization, CI checks and Kubernetes admission — without mixing up which tool does what, plus what changed in a recent parser fix for anyone already using OPA's newer Rego syntax.

Where OPA fits beyond Kubernetes

The core project — open-policy-agent/opa on GitHub, with roughly 12.3 thousand stars and 1.7 thousand forks — is a policy engine that evaluates a request against a written policy instead of hard-coded application logic. MSPs and product teams use it anywhere that kind of decision needs to happen, not only at the edge of a Kubernetes cluster.

The Rego policy language it runs applies just as well at an API gateway or inside a service sidecar, evaluating whether a request is authorized before it reaches application code. The same policy packs can be reused in CI pipelines to catch violations, such as a forbidden dependency, a misconfigured resource or an unapproved region, before a change is deployed rather than after.

OPA, Gatekeeper and Conftest are three different things

Kubernetes admission control through Gatekeeper is one integration built on top of OPA, not OPA itself, and Conftest is a separate command-line tool for testing structured configuration files against Rego policies. Collapsing all three into a single OPA story in customer-facing material overstates what any one tool does on its own: each has its own deployment model and its own failure modes.

Gatekeeper: enforcing policy at the Kubernetes front door

OPA Gatekeeper, maintained under the Open Policy Agent organization on GitHub with around 4.3 thousand stars, is a Kubernetes admission controller. It intercepts API requests through a validating admission webhook and checks them against Rego policies at the moment a workload is submitted, rather than after it is already running. For an MSP managing multiple customer clusters, a rule can be written once and enforced consistently: require container images from an approved registry or with a verified signature attestation, deny containers that request privileged mode or unrestricted hostPath mounts, or restrict which workload kinds a given namespace can accept.

Gatekeeper is a Kubernetes-specific integration, not a replacement for the core engine, which MSPs also use for API authorization and CI checks outside Kubernetes; the two are complementary, with Gatekeeper owning the admission path while the core engine handles policy decisions elsewhere in the stack. It is not a substitute for RBAC, network policy or secrets hygiene either — it adds a layer on top of them, not instead of them.

September 2026: a parser bug fixed in OPA 1.20.2

OPA 1.20.2, released in early September 2026, fixes a parser bug introduced two releases earlier in 1.20.0, which had added new and and or Rego keywords for combining conditions inside a single rule body. When a policy imported those keywords, directly or via import future.keywords, OPA's parser first read a statement starting with a brace as an operand body, then re-read it as a term, such as a comprehension, if no and or or followed.

A regression meant errors recorded during that first, abandoned read stayed cached and were wrongly reported against the second, successful read, so the parser rejected some policies that were actually valid. Policies that don't import and/or were never affected, and this is a narrow bug fix rather than a security advisory; the companion opa-envoy-plugin project shipped a matching v1.20.2-envoy release alongside it, so teams running that plugin should confirm they picked up the same version bump.

MSPs that want outside verification of these controls as part of a NIS2, DORA or GDPR compliance program can draw on dedicated support: Altovar's cybersecurity services cover penetration testing, vulnerability assessment, incident response and compliance work for those same frameworks.

Practical starting points

• API authorization: evaluate Rego policies at the gateway or sidecar layer for requests that need per-tenant or per-role rules beyond a framework's built-in auth.
• CI policy gates: run the same Rego rules against infrastructure-as-code or manifests in a pipeline step, failing the build on violations instead of relying on manual review.
• Kubernetes admission: start Gatekeeper policies in dry-run or warn mode, document exceptions for existing workloads, and scope constraints to specific namespaces before expanding.
• Shared policy libraries: write rules once and apply them across admission control, API authorization and CI instead of re-implementing the same logic three times.

What to do

1. Map where policy decisions currently live in your stack — admission, gateway, CI — and flag the ones still hard-coded instead of policy-based.
2. If you run Gatekeeper, roll out new constraints in dry-run or warn mode and document exceptions before switching to enforce.
3. Keep the three tools distinct in your own documentation: the OPA engine, Gatekeeper for admission, and Conftest for CI and config testing.
4. If your Rego policies import the and/or keywords, confirm you are on OPA 1.20.2 or later before treating a rejected policy as an authoring mistake.
5. Check whether dependent tooling, such as the Envoy plugin or sidecars, picked up the same OPA version bump.
6. Pair admission and authorization policies with RBAC, network policy and secrets hygiene rather than treating them as a full replacement.

Sources: GitHub — open-policy-agent/opa, GitHub — open-policy-agent/opa releases, GitHub — open-policy-agent/gatekeeper.