OPA Gatekeeper: Enforce Kubernetes Policies as Code

WHY IT EXISTS: Organizations need to enforce security, governance, and best practices across their Kubernetes clusters. Manually checking every resource change is impossible at scale. Gatekeeper automates policy enforcement directly within the Kubernetes API lifecycle, ensuring consistency and providing immediate feedback to developers.

THE MENTAL MODEL: Think of Gatekeeper as a programmable bouncer for your Kubernetes API server. When a request comes in to create or change an object, like a Pod or Service, the API server asks Gatekeeper, "Is this allowed?" Gatekeeper checks its rulebook—your policies—and gives a thumbs-up or thumbs-down, rejecting non-compliant resources before they are ever created.

HOW IT WORKS: Gatekeeper registers as a validating and mutating admission controller webhook in Kubernetes. When you run kubectl apply, the API server forwards the resource to Gatekeeper. Gatekeeper then uses the Open Policy Agent (OPA) engine to evaluate the resource against policies you've defined as native Kubernetes Custom Resource Definitions (CRDs). Policies are defined with ConstraintTemplates (the reusable logic) and applied with Constraints (the specific enforcement). If a resource violates a policy, the API server rejects the request. Gatekeeper can also audit existing resources for violations and mutate incoming objects to enforce standards.

WHEN TO USE IT: Use Gatekeeper for centralized, automated policy enforcement. Common use cases include: mandating that all Deployments have resource limits, requiring specific labels for cost tracking, blocking containers from insecure registries, or preventing privileged Pods from being created in certain namespaces.

WHEN NOT TO USE IT: For very simple, static validation that rarely changes, a custom-coded admission webhook might be an option, though it's less flexible. Gatekeeper is specifically designed for Kubernetes resource policy; if your policies don't involve Kubernetes objects, a different OPA integration point is more appropriate.

ONE CANONICAL EXAMPLE: A common policy is to prevent developers from using the :latest image tag, which is not a stable reference. You would define a ConstraintTemplate with the logic to check image tags. Then, you would create a Constraint that applies this template to all Pods, rejecting any that specify an image with the :latest tag. This prevents non-deterministic deployments and enforces best practices automatically.