Introduction
OPA Gatekeeper brings the Open Policy Agent (OPA) into the Kubernetes admission control flow as a native validating and mutating webhook. Instead of writing policies in raw OPA configurations, Gatekeeper introduces Kubernetes-native CRDs — ConstraintTemplates and Constraints — that make policy management declarative and auditable.
What OPA Gatekeeper Does
- Validates Kubernetes API requests against custom policies before resources are persisted
- Mutates resources to inject defaults, labels, or annotations according to policy
- Audits existing cluster resources for policy violations on a configurable schedule
- Provides a library of reusable constraint templates for common governance patterns
- Reports policy violation status through Kubernetes resource conditions and events
Architecture Overview
Gatekeeper runs as a Kubernetes deployment that registers itself as a validating and mutating admission webhook. When the API server receives a create/update/delete request, it sends an admission review to Gatekeeper. Gatekeeper evaluates the request against compiled Rego policies from ConstraintTemplates and returns allow/deny decisions. The audit controller periodically scans existing resources for retroactive compliance checks.
Self-Hosting & Configuration
- Install via Helm chart or raw manifests from the Gatekeeper releases
- Define ConstraintTemplates with Rego policy logic, then instantiate Constraints to activate them
- Configure the webhook to target specific API groups, kinds, and namespaces using match rules
- Use the
ConfigCRD to sync external data (e.g., all namespaces, ingresses) into OPA for cross-resource policies - Set
--audit-intervalto control how frequently existing resources are checked for violations
Key Features
- Constraint template library with pre-built policies for image registries, labels, resource limits, and more
- External data support for policies that reference resources outside the admission request
- Mutation support for injecting sidecar annotations, default labels, or enforcing naming conventions
- Dry-run enforcement action for testing policies without blocking deployments
- Prometheus metrics for policy evaluation latency, violation counts, and webhook health
Comparison with Similar Tools
- Kyverno — Kubernetes-native policy engine using YAML instead of Rego, lower learning curve
- OPA (standalone) — general-purpose policy engine; Gatekeeper adds Kubernetes-specific CRDs and audit
- Kubewarden — policy engine using WebAssembly, supporting policies in multiple languages
- Polaris — best-practice validation focused on workload configuration, less customizable
- Pod Security Standards — built-in Kubernetes admission control, limited to pod security
FAQ
Q: Do I need to learn Rego to use Gatekeeper? A: Writing custom ConstraintTemplates requires Rego. However, the community-maintained library provides many ready-to-use templates that only need parameter configuration.
Q: What happens if Gatekeeper is unavailable?
A: By default, the webhook is configured with failurePolicy: Ignore, so API requests proceed if Gatekeeper is down. This can be changed to Fail for stricter enforcement.
Q: Can Gatekeeper mutate resources? A: Yes. Gatekeeper supports mutation through Assign, AssignMetadata, and ModifySet CRDs for injecting or modifying fields on resources during admission.
Q: How does audit differ from admission? A: Admission blocks non-compliant resources at creation time. Audit periodically scans already-existing resources and reports violations without modifying them.