A Kubernetes admission controller is a piece of cluster logic that intercepts requests to the Kubernetes API server after authentication and authorization but before an object is persisted to etcd. If you've ever wondered what is a Kubernetes admission controller and why it matters for security, the short answer is that it's the last programmable checkpoint standing between a kubectl apply and a running workload. Admission controllers can inspect, reject, or modify incoming requests — a Pod spec requesting privileged mode, an Ingress missing TLS, a container pulling from an untrusted registry — before the cluster ever acts on them. Kubernetes ships with built-in controllers (like NamespaceLifecycle or LimitRanger), but the real power for security teams comes from dynamic admission control: validating and mutating webhooks that call out to custom logic, enabling policy enforcement tailored to an organization's supply chain and compliance requirements.
What is a Kubernetes admission controller, exactly?
A Kubernetes admission controller is a compiled-in or dynamically registered plugin that sits in the API server's request pipeline, running after the request has been authenticated and authorized (RBAC has already said "yes, this user can create Pods") but before the object is written to storage. Admission control happens in two phases: mutating admission, which can alter the object (injecting a sidecar, adding labels, setting default resource limits), and validating admission, which can only accept or reject the object as-is. Every request — whether from a developer running kubectl, a CI/CD pipeline, or a controller reconciling a Deployment — passes through this chain. If any admission controller in the chain rejects the request, the API server returns an error and nothing is persisted. This makes admission control the natural place to enforce security policy, because by the time a workload reaches the scheduler, it has already been vetted.
How do validating and mutating webhooks differ?
A mutating webhook Kubernetes admission controller can change the object before it's saved, while a validating admission webhook can only allow or deny it — this ordering matters because mutations always run first, so validation sees the final version of the object. Both are configured through MutatingWebhookConfiguration and ValidatingWebhookConfiguration resources, which tell the API server which HTTP endpoint to call, which resources and operations to intercept, and what to do if that endpoint is unreachable (failurePolicy: Fail or Ignore). In practice, a mutating webhook might automatically inject a Safeguard sidecar for runtime attestation, rewrite an image reference to a pinned digest instead of a mutable tag, or add a seccompProfile. A validating webhook, running afterward, checks the resulting spec against policy — for example, rejecting any Pod that still references latest as an image tag, or one lacking a signed provenance attestation. Because webhooks are just HTTPS services returning an AdmissionReview response, teams can write them in any language, but most production deployments today build on a policy engine rather than hand-rolled webhook servers, since raw webhooks require you to manage TLS certificates, availability, and versioning yourself.
How does admission control policy enforcement actually stop bad deployments?
Admission control policy enforcement works by codifying rules as machine-readable policy that the webhook evaluates against every incoming object, returning allowed: false with a human-readable reason when a rule is violated. A concrete example: a bank running a multi-tenant Kubernetes platform wants to guarantee that no container image can run unless it was built by an approved CI pipeline and signed with Sigstore/cosign. They deploy a validating webhook that, on every Pod creation, extracts the image digest, checks it against a signature transparency log, and denies the request if verification fails or if the image originates from an unapproved registry. The same mechanism enforces dozens of other rules simultaneously — no hostNetwork: true, no containers running as root, mandatory resources.limits, no wildcard RBAC bound to workload service accounts. Because enforcement happens at admission time rather than through periodic scanning, a misconfigured or malicious manifest never gets a chance to run, closing the gap between "detected" and "prevented" that plagues after-the-fact security tooling.
Why do so many teams use OPA Gatekeeper for admission control instead of custom webhooks?
Most teams adopt OPA Gatekeeper admission control because it turns policy-as-code into a first-class Kubernetes resource instead of a bespoke webhook service every team has to build and maintain. Gatekeeper is a validating (and now mutating) admission controller built on the Open Policy Agent's Rego language, packaged as ConstraintTemplate and Constraint custom resources. Instead of writing and hosting a webhook that says "reject Pods without resource limits," a platform team writes a Rego policy once, and Gatekeeper's ConstraintTemplate CRD generates a reusable constraint that can be parameterized per namespace or team — for instance, requiring stricter image-registry allowlists in the payments namespace than in dev. Gatekeeper also supports audit mode, continuously evaluating existing cluster objects against constraints and reporting violations without blocking anything, which lets teams roll out new policy safely before flipping it to enforce. Other engines, like Kyverno, take a similar approach with native Kubernetes-style YAML instead of Rego, but the underlying admission-webhook mechanism is identical: intercept, evaluate, allow or deny.
What happens when an admission controller is misconfigured or goes down?
When an admission controller is misconfigured or its endpoint is unreachable, the cluster's behavior depends entirely on the failurePolicy set in its webhook configuration, and getting this wrong has caused real outages. In a widely cited 2019 Kubernetes incident, a cluster-wide validating webhook with failurePolicy: Fail and no matching namespaceSelector exclusion started rejecting all API requests — including requests to fix the webhook itself — because the webhook's own backing pod had crashed and every request to the API server, including kubectl delete on the broken webhook configuration, was itself intercepted and denied. The cluster effectively locked itself out. This is why production Gatekeeper and Kyverno deployments carefully scope webhooks with namespaceSelector exclusions for kube-system, run multiple replicas behind a Service for high availability, and default new policies to failurePolicy: Ignore or dry-run/audit mode until they've been validated against real traffic. Admission control is powerful precisely because it's in the critical path — which means an unreliable admission controller can take down cluster operations just as effectively as it can stop an attacker.
How Safeguard Helps
Safeguard treats the admission controller as a critical enforcement point in the software supply chain, not just a Kubernetes networking detail. Instead of asking teams to hand-write Rego or Kyverno policies and hope they cover every risky configuration, Safeguard maps admission control policy enforcement directly to supply chain evidence: SBOM contents, image provenance, signature verification, and vulnerability scan results generated earlier in the CI/CD pipeline. When a Pod is created, Safeguard's admission layer can validate that the image digest matches a signed, attested build artifact — rejecting anything that wasn't produced by a known pipeline — while flagging policy drift across clusters so a rule enforced in production isn't silently absent in staging. Safeguard also provides audit-first rollout for new policies, visibility into which webhooks are active across a fleet of clusters, and guardrails (like automatic namespaceSelector exclusions and multi-replica webhook health checks) that prevent the exact kind of self-inflicted lockout that misconfigured failurePolicy: Fail settings have caused elsewhere. The result is admission control that enforces real supply chain guarantees — signed images, verified provenance, least-privilege workloads — without turning the API server into a single point of failure.