Wiki · Concept · Last reviewed June 25, 2026

OPA Gatekeeper

OPA Gatekeeper is a Kubernetes policy controller that uses Open Policy Agent and Kubernetes custom resources to evaluate admission-time constraints before workloads enter a cluster.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: OPA Gatekeeper, Kubernetes, admission control, Rego, AI governance

Definition

OPA Gatekeeper is the Kubernetes-focused policy controller in the Open Policy Agent ecosystem. OPA's ecosystem page describes it as a Rego policy controller for Kubernetes that manages admission policies using custom resources. The project repository describes Gatekeeper as "Policy Controller for Kubernetes" and lists native Kubernetes custom resources for constraints, constraint templates, mutation support, audit functionality, and external data support.

The practical meaning is narrower than "AI governance" and broader than a lint rule. Gatekeeper sits in the Kubernetes admission path, where cluster requests are checked before resources are persisted. It can reject a workload manifest, warn about it, dry-run a policy result, or report violations discovered by audit. In AI infrastructure, that makes it a control point before model servers, evaluation workers, agent tool containers, and automation jobs receive cluster authority.

How It Works

Gatekeeper's validation model uses two main resource types. A ConstraintTemplate defines the Rego logic and the schema of parameters that administrators can tune. A Constraint instantiates that template for selected Kubernetes resources and supplies concrete parameters. The official how-to says validation uses ConstraintTemplate and Constraint resources to evaluate Kubernetes objects, and that admission decisions can deny, warn, or dry-run requests while audit mode evaluates existing resources and reports violations.

Gatekeeper is not the same thing as Open Policy Agent itself. OPA is the general-purpose policy engine and Rego language. Gatekeeper is the Kubernetes integration that turns selected Rego policies into admission and audit behavior through Kubernetes APIs. The official admission-behavior page says Gatekeeper is a Kubernetes admission webhook and identifies its default validating webhook configuration.

Kubernetes admission control is the wider platform mechanism underneath this. The Kubernetes documentation says admission controllers check data in requests to modify resources, apply to create, delete, or modify operations, and do not block ordinary read operations. Kubernetes also has a native ValidatingAdmissionPolicy feature, stable since Kubernetes v1.30, that uses CEL expressions as an in-process alternative to validating admission webhooks. Gatekeeper remains relevant when an organization wants OPA, Rego, Gatekeeper's constraint model, audit behavior, or existing policy-library patterns.

Agent Context

The AI relevance is architectural, not magical. Agents and model systems often become Kubernetes workloads: a model-serving deployment, a vector database, a tool server, a browser automation worker, a batch evaluator, or a code-execution sandbox. If those workloads are created by humans, CI pipelines, or deployment agents, admission policy becomes one of the last programmable stops before runtime authority.

Gatekeeper can express local rules such as requiring owner labels, blocking privileged containers, requiring digest-pinned images, rejecting host namespace access, limiting which namespaces can run tool servers, or requiring evidence from another admission-time verifier such as Ratify. Those examples are policy choices an operator can encode; they are not claims that Gatekeeper understands model intent or user safety. The tool evaluates Kubernetes objects and policy input. The organization decides what those objects are allowed to do.

Governance Use

A governance-grade Gatekeeper deployment should preserve more than the final allow or deny. Useful records include the Kubernetes resource kind and name, namespace, user or service account, admission operation, constraint template, constraint, Rego policy version, parameters, enforcement action, violation message, exception path, and audit result. If policy is tied to supply-chain evidence, preserve the image digest, signing or SBOM verifier, and any controller that contributed a decision.

Gatekeeper also belongs in change management. Constraint templates are executable policy artifacts; changing one can affect many namespaces and teams at once. A strong review process treats templates and constraints as production controls: tested, versioned, reviewed, staged, and paired with an owner who can explain the reason for the rule.

Limits

Gatekeeper is an admission and audit control, not a behavioral evaluator for AI systems. It does not inspect prompts, judge generated text, detect deception, prove alignment, or decide whether a model is safe. It can stop a workload whose Kubernetes configuration violates policy. After the workload is admitted, runtime behavior needs other controls: network policy, workload identity, logging, sandboxing, rate limits, human review, and incident response.

Operational settings matter. Gatekeeper's admission-behavior documentation notes timeout and failure-policy choices for webhooks, including the tradeoff between availability and enforcement when a webhook is unavailable. It also notes that deletes are not auditable once a resource is gone. These details should be part of the control narrative. A policy that only works when the webhook is reachable, scoped correctly, and not bypassed by exemptions is still useful, but it is not absolute.

Source Discipline

Claims about Gatekeeper should cite Gatekeeper documentation, the open-policy-agent/gatekeeper repository, OPA ecosystem material, and Kubernetes admission-control documentation. Claims about AI should be labeled as an infrastructure inference: Gatekeeper governs Kubernetes resource admission, and AI relevance follows when agent and model infrastructure is deployed through Kubernetes.

Do not collapse Gatekeeper into all policy-as-code. OPA, Gatekeeper, Kubernetes ValidatingAdmissionPolicy, Cedar, OpenFGA, and ordinary CI checks can all enforce policy, but they operate at different layers and answer different questions.

Spiralist Reading

Spiralism reads Gatekeeper as a refusal to let deployment become pure momentum. Before the agent gets its pod, credentials, network, and toolchain, a rule gets to ask whether this object belongs here.

The ritual is intentionally dry: a template, a constraint, a resource, a decision. That dryness is its virtue. It gives the institution a place to write down what it means by "allowed" before automation turns intention into running infrastructure.

Sources

Return to Wiki