Admission Controller

Admission controllers sit in the critical path between authentication/authorization and object persistence. They inspect every create, update, and delete request to the API server, providing a centralized enforcement point for security policies. This includes requests from users, service accounts, and internal controllers. The webhook call is a synchronous HTTPS request, meaning the API server blocks until the admission controller responds, making latency a critical design consideration.

The admission process runs in two distinct phases. Mutating admission controllers run first and can modify objects—injecting sidecar proxies, adding default labels, or setting resource limits. Validating admission controllers run second and can only accept or reject requests. This ordering ensures that validators inspect the final, mutated object. A common pattern is using a mutating webhook to inject an Istio sidecar, followed by a validating webhook to enforce that all pods have a sidecar present.

To minimize latency and reduce the blast radius of misconfigured webhooks, admission controllers support fine-grained scoping via objectSelector and namespaceSelector fields. These use Kubernetes label selectors to target only specific namespaces or objects. For example, a security policy for PCI-compliant workloads can be scoped to namespaceSelector: matchLabels: { compliance: pci }, ensuring non-sensitive workloads are never blocked by the webhook.

Kubernetes ships with over 30 built-in admission controllers compiled into the API server binary, including PodSecurity, ResourceQuota, and LimitRanger. External controllers run as separate services and communicate via webhooks. Built-in controllers are always available and have zero network latency, but external controllers offer greater flexibility and can integrate with third-party policy engines like Open Policy Agent (OPA) or Kyverno.

The practice of writing security and compliance rules in a high-level programming language, storing them in version control, and applying automated testing and deployment pipelines. Admission controllers are the enforcement point for policy-as-code workflows. Key benefits include:

• Auditability: Every policy change is tracked in Git history
• Reproducibility: Policies are applied identically across dev, staging, and production
• Drift prevention: The desired state is continuously reconciled against live clusters

The practice of referencing a container image by its immutable content-addressable SHA256 hash rather than a mutable tag like :latest. An admission controller can enforce digest pinning by rejecting any pod spec that references a floating tag. This guarantees that the exact same artifact is deployed every time, eliminating the risk of tag mutation attacks where an attacker overwrites a known tag with a malicious image.

A security profile that blocks all system calls by default for a containerized process, explicitly allowing only a minimal set required for the application to function. An admission controller can mutate incoming pod specs to attach restrictive seccomp profiles automatically, ensuring no workload runs with excessive kernel privileges. This defense-in-depth approach reduces the kernel attack surface even if an attacker achieves code execution.