OPA Gatekeeper 2026: Kubernetes Policy Controller

OPA Gatekeeper is a Kubernetes admission controller that brings Open Policy Agent to cluster policy enforcement. Part of the CNCF graduated OPA project, Gatekeeper has 4.1k GitHub stars and 249 contributors. The latest release is v3.21.1 (February 2026), running OPA v0.60.0 under the hood.

Gatekeeper uses a “configure, not code” approach where policies are defined using Rego and Kubernetes CRDs. This eliminates the need to build custom admission webhooks while keeping OPA’s full policy flexibility.

What is OPA Gatekeeper?

Gatekeeper operates as a validating and mutating admission webhook in Kubernetes. When resources are created or updated, the Kubernetes API server sends them to Gatekeeper for evaluation before persisting to etcd. Gatekeeper runs policies written in Rego and either allows or denies the request based on policy evaluation.

The project introduces two key CRDs: ConstraintTemplate and Constraint. ConstraintTemplates define reusable policy logic in Rego. Constraints instantiate those templates with specific parameters and enforcement configurations. This separation allows policy authors to write Rego once and platform teams to apply it with different settings across namespaces.

Gatekeeper also provides audit functionality that continuously scans existing cluster resources for policy violations. This feature identifies drift when resources are modified outside admission control or when policies are added after resources already exist.

Rego Policy Language

Leverage OPA’s powerful Rego language for complex policy logic, enabling fine-grained control over resource admission

Policy Library

Access a collection of pre-built ConstraintTemplates covering common security and compliance requirements, accelerating policy adoption

Audit Mode

Continuously scan existing resources against policies to detect violations and compliance drift without blocking deployments

Key Features

Feature	Details
Policy language	Rego (OPA)
CRD types	ConstraintTemplate, Constraint, Mutation
Enforcement modes	Deny, dry-run, audit
External data	Support for external data sources in policies
OPA version	v0.60.0
Policy library	Reusable ConstraintTemplates from the Gatekeeper Library
CNCF status	Graduated (as part of OPA)
License	Apache 2.0

ConstraintTemplate System

The template-constraint pattern promotes policy reuse. A single ConstraintTemplate defining “required labels” can be instantiated multiple times with different label requirements for different namespaces or resource types. This pattern reduces policy duplication and simplifies maintenance.

Dry Run Testing: Gatekeeper supports dry-run mode where policies can be tested against live traffic without actually enforcing them. This capability allows teams to validate policy behavior before enabling enforcement, reducing the risk of accidentally blocking legitimate workloads.

Namespace Exclusions: Policies can be configured to exclude system namespaces or specific workloads. This flexibility prevents policies from interfering with critical cluster components while still enforcing standards on application workloads.

Policy Bundle Distribution: Gatekeeper integrates with OPA’s bundle distribution mechanism, allowing centralized policy management. Organizations can publish policies to a bundle server and have Gatekeeper instances pull updates automatically.

Mutation Support: Gatekeeper supports mutating admission through native Kubernetes CRDs. This enables use cases like injecting sidecars, setting default resource limits, or adding required labels before resources are admitted.

Enforcement architecture

Gatekeeper deploys as a Kubernetes controller with admission webhook endpoints registered with the API server. When admission requests arrive, Gatekeeper evaluates them against active Constraints. Each Constraint references a ConstraintTemplate and specifies which resources it applies to through match criteria.

The Rego engine evaluates the resource against the template’s policy logic. If the policy denies the resource, Gatekeeper returns a rejection to the API server with a message defined in the Constraint. The resource creation fails and the user receives the denial message.

The audit controller runs periodically, querying all cluster resources that match active Constraints. For each resource, it evaluates the policy and records violations in the Constraint’s status field. This creates an audit trail showing which resources violate which policies without requiring manual scanning.

Mutation works similarly but modifies resources before validation. Mutating webhooks are called before validating webhooks in the Kubernetes admission chain. Gatekeeper can apply transformations defined in Mutation CRDs, then the modified resource proceeds through validation.

Getting Started

Install Gatekeeper — Deploy using Helm or kubectl apply from the official release manifests. Gatekeeper registers admission webhooks with the Kubernetes API server.

Add ConstraintTemplates — Apply ConstraintTemplates from the Gatekeeper policy library or write your own in Rego. Templates define the policy logic.

Create Constraints — Instantiate Constraints that reference templates with specific parameters and match criteria. Use dry-run mode first to test without enforcing.

Review audit results — Gatekeeper’s audit controller continuously scans existing resources. Check Constraint status fields for violations in resources that predate the policy.

When to Use OPA Gatekeeper

Strengths:

Graduated CNCF project with strong enterprise adoption
Rego provides powerful, flexible policy language
Large policy library reduces time to value
Integration with broader OPA ecosystem and tooling
Audit capabilities detect policy violations in existing resources
Template-constraint pattern promotes policy reuse

Limitations:

Rego has a steeper learning curve than YAML-based alternatives
Mutation support is less mature than validation
Policy debugging can be challenging without proper tooling
Performance overhead increases with complex policies and large clusters
Requires understanding of both Kubernetes and Rego

Best for

Organizations with complex policy requirements where Rego’s expressiveness justifies the learning curve. Ideal for teams already using OPA in other parts of their infrastructure who want consistent policy tooling.

OPA Gatekeeper fits into a comprehensive IaC security strategy alongside runtime detection tools like Falco and container scanners. Teams often use Gatekeeper for admission control policies while relying on tools like kube-bench for cluster configuration auditing. The combination provides defense in depth across different stages of the deployment lifecycle.

Frequently Asked Questions

What is OPA Gatekeeper?

OPA Gatekeeper is a Kubernetes admission controller that uses Open Policy Agent (OPA) to enforce custom policies. It allows organizations to define and enforce policies using the Rego language through Kubernetes custom resources, preventing non-compliant resources from being created.

How does Gatekeeper differ from standalone OPA?

While standalone OPA requires building custom admission webhooks, Gatekeeper provides a complete Kubernetes-native integration. It uses CRDs for policy definition, includes audit capabilities, provides a policy library, and handles webhook configuration automatically.

What is the ConstraintTemplate pattern?

ConstraintTemplate is Gatekeeper’s way of defining reusable policy templates in Rego. Teams write a template once, then create multiple Constraint instances with different parameters. This approach promotes policy reuse and reduces code duplication.

Can Gatekeeper modify resources like Kyverno?

Yes, Gatekeeper supports mutation through native Kubernetes CRDs. However, its primary strength is validation. Kyverno offers more mature mutation capabilities including resource generation and cleanup if your use case is mutation-heavy.