What it does
Gatekeeper is a validating and mutating admission webhook backed by the OPA evaluation engine. It splits policy into two custom resources. A ConstraintTemplate contains the Rego, defines the parameters the policy accepts, and generates a new CRD. A Constraint is an instance of that template: it selects which kinds and namespaces the policy applies to and supplies the parameters. That separation means one person writes the Rego once and others configure it declaratively, which is how a policy library gets shared across teams that do not all write Rego.
Two mechanisms matter operationally. Audit runs the same constraints against resources already in the cluster on a schedule and records violations in the constraint's status, so you can see existing noncompliance without blocking anything. The replication feature caches selected resources into OPA so a policy can reason about cluster state, for example rejecting an Ingress whose hostname collides with one already in use.
Where it fits
Gatekeeper sits at the Kubernetes API server admission boundary, owned by platform engineering. The standard rollout is dryrun enforcement first, review the audit violations, remediate existing resources, then switch to deny. The Gatekeeper CLI lets the same constraints run against manifests in CI, which is worth doing: catching a violation at admission time is late feedback for a developer. The Gatekeeper Library provides community constraint templates covering the usual controls, so you need not start from an empty policy set.
Strengths
- Constraint templates decouple policy authorship from policy configuration, which scales across teams with mixed Rego skills.
- Audit mode plus violation status makes the existing estate's noncompliance visible before anything is blocked.
- Rego skills and policy logic carry over to other OPA deployments, including service authorization and Conftest in CI.
- The community constraint template library covers common Kubernetes controls without writing Rego at all.
Limitations
- Rego is a real barrier. Teams frequently adopt Gatekeeper, use only library templates, and never write their own, which limits it to generic controls.
- It validates and can mutate, but it does not generate companion resources, so paved-road patterns that create defaults need something else.
- The webhook is on the API server critical path, and the resource replication cache adds memory pressure proportional to what you replicate. Both need capacity planning and careful failure policy settings.
Who it suits
Right for organizations that already run OPA and want one policy language across admission control, CI and application authorization. Wrong for a team whose Kubernetes operators work in YAML and have no appetite for Rego, and wrong where automatic resource generation or mutation-heavy paved-road patterns are the main goal.
Used OPA Gatekeeper? Recommend it under your own name and title.
Recommend this tool