OPA/Gatekeeper

What it is

Gatekeeper is a Kubernetes admission controller that enforces policy on API requests using Open Policy Agent (OPA) as the decision engine. It runs as a validating (and optionally mutating) webhook: when someone creates or updates a resource, Gatekeeper intercepts the request, evaluates it against constraints written in Rego, and allows or rejects it before it hits etcd. Policies are defined via two CRDs — ConstraintTemplate (the Rego logic) and Constraint (the parameters applied to that logic) — so you get reusable policy libraries instead of one-off scripts. Common use cases: blocking privileged containers, requiring resource limits, enforcing label conventions, restricting image registries.

Who builds it and why

Gatekeeper is a CNCF project incubated under the Kubernetes Policy Working Group, built on top of OPA (also CNCF). It exists because raw OPA has no native Kubernetes integration — Gatekeeper is the glue that makes OPA usable as an admission controller with proper CRD-based UX, audit functionality, and constraint templating. 266 contributors is a healthy, broad base rather than a single-vendor pet project, which matters for a component that sits in the request path of every cluster mutation.

Production readiness signal

• 4,235 GitHub stars — solid adoption for infrastructure tooling, though lower than some competing policy engines (see below).
• 266 contributors — wide contributor base, not dependent on one company's headcount.
• Active releases — v3.22.2 latest, with commit activity continuing (last commit logged 2026-06-30 per repo data).
• CNCF maturity level — not publicly available in the data provided; check the CNCF landscape directly before citing a maturity tier in a compliance doc.
• License — Apache-2.0, no vendor lock-in risk from licensing terms.
• Language — Go, consistent with the rest of the Kubernetes ecosystem; no JVM or Python runtime dependency to manage.

Gatekeeper has been running in production clusters for years across large orgs (used widely in regulated environments needing policy-as-code audit trails). It's not experimental. The real risk isn't stability — it's operational complexity: webhook failure modes, Rego debugging, and constraint template sprawl if not governed.

Who should use this

• Platform teams that need policy-as-code with version control, code review, and CI testing of cluster-wide rules (Pod Security, network policy shape, naming, registry allowlists).
• Organizations already invested in OPA/Rego elsewhere (API gateways, CI pipelines) who want one policy language across the stack.
• Multi-tenant clusters where fine-grained, auditable admission control is a compliance requirement, not a nice-to-have.
• Teams comfortable maintaining Rego — it's a real language with a real learning curve, not YAML templating.

Who should NOT use this

• Small teams or single-tenant clusters where Kubernetes' built-in Pod Security Admission (PSA) already covers your needs — Gatekeeper is overkill if you just need baseline pod security standards.
• Teams that don't want to learn Rego. It's a legitimate barrier; if nobody on the team can debug a failing constraint at 2am, you've added an outage vector, not removed one.
• Clusters with very high admission request volume and low tolerance for added webhook latency — every create/update now round-trips through Gatekeeper's webhook, and misconfigured failurePolicy can block deployments cluster-wide.
• Anyone wanting a GUI-first, no-code policy experience — Gatekeeper is CLI/YAML/Rego native. If your team wants low-code compliance dashboards, look elsewhere first.

Alternatives

• Kyverno — Kubernetes-native policy engine using YAML instead of Rego; lower learning curve, faster adoption for teams that don't want a new DSL.
• Kubernetes Pod Security Admission (PSA) — built into Kubernetes core, covers basic pod security standards without installing anything, but far less flexible than Gatekeeper for custom business rules.
• Kubewarden — WASM-based policy engine, lets you write policies in Rust/Go/AssemblyScript instead of Rego; worth a look if your team wants a general-purpose language.

Pricing

Fully open source, Apache-2.0. No paid tier, no enterprise gate. Cost is operational: engineering time to write and maintain Rego policies, plus whatever compute overhead the webhook adds to your admission path.