Gatekeeper vs OPA

TL;DR

• OPA: a general-purpose policy engine that knows nothing about k8s.
• Gatekeeper: bridging OPA to the k8s world; think of it as a big Validating Admission Webhook.

1. The Core Relationship

• OPA (Open Policy Agent) is the engine. It is a general-purpose, platform-agnostic policy engine. It can be used to make decisions for anything: Microservices, Terraform, SSH, Kafka, or Kubernetes.
• Gatekeeper is the car. It is a project built specifically for Kubernetes that uses OPA under the hood. It provides a "Kubernetes-native" way to use OPA.

2. OPA (The Generalist)

OPA was designed to solve the problem of "Policy-as-Code" across an entire tech stack.

• How it works: You send OPA some data (JSON) and a policy (written in a language called Rego). OPA evaluates them and returns a decision (Allow/Deny).
  • It is designed to be completely domain-agnostic, everything is just JSON. It doesn't know what a "Pod," a "Service," or a "Custom Resource Definition (CRD)" is.
• Where it lives: It can run as a sidecar, a standalone service, or a library.
• Pros: Works everywhere; extremely flexible.
• Cons in Kubernetes: Using "raw" OPA in Kubernetes is difficult. You have to manually manage Admission Webhooks, and updating policies requires redeploying ConfigMaps or rebuilding containers.

3. Gatekeeper (The K8s Specialist)

Gatekeeper was created by the OPA community and Google/Microsoft/RedHat to make OPA easy to use within a Kubernetes cluster.

• How it works: It acts as a Custom Controller. You don't have to write raw Rego files and mount them; instead, you use CRDs (Custom Resource Definitions).
  • At its core, Gatekeeper is a Validating Admission Webhook.
  • Meanwhile, Gatekeeper is a Control Plane service. gatekeeper-controller-manager is a deployment within the cluster.
• Key Concept: Constraints & Templates:
  • ConstraintTemplate: You define the Rego logic (e.g., "Labels are required").
  • Constraint: You apply that logic to a specific resource (e.g., "The 'Owner' label is required on all Namespaces").
• Pros: Native to K8s tools (kubectl, Helm); provides auditing features (scanning existing resources for violations); handles the Admission Webhook setup automatically.
• Cons: It only works for Kubernetes.

4. Key Differences at a Glance

Feature	OPA (Open Policy Agent)	Gatekeeper
Scope	General-purpose (Any system)	Kubernetes-only
Language	Rego	Rego (wrapped in CRDs)
Configuration	Raw Rego files / API calls	Kubernetes CRDs (YAML)
Audit Feature	No native "audit" of existing state	Yes (Finds existing non-compliant pods)
Complexity	High (for K8s setup)	Low (built-in for K8s)
Data Awareness	Requires manual context injection	Can "sync" K8s data (like Namespaces) easily

5. Why use Gatekeeper instead of just OPA?

If you are working in Kubernetes, Gatekeeper is almost always the better choice for these three reasons:

1. Native YAML Workflow: Platform engineers are already comfortable with YAML. Gatekeeper lets you manage policies as YAML objects just like Pods or Services.
2. Audit Functionality: OPA usually only checks things as they are being created (Admission Control). Gatekeeper can constantly scan your cluster and report: "Hey, these 10 Pods were created before this rule existed, and they are currently violating it."
3. Parameterization: With Gatekeeper, you can write one piece of logic (a Template) and reuse it many times with different parameters (Constraints) without rewriting the Rego code.

Summary

• Use OPA if you need a policy engine for your custom App, your CI/CD pipeline, or your Terraform plan.
• Use Gatekeeper if you want to enforce rules inside a Kubernetes cluster (e.g., "Every container must have a resource limit," or "Don't allow images from untrusted registries").