Admission Controller

These controllers intercept requests before validation and can modify the object. They are called first in the admission chain.

• Defaulting: Automatically inject sidecar containers, volume mounts, or environment variables.
• Image Tag Resolution: Convert mutable tags like latest to immutable digests.
• Pod Identity: Attach service mesh proxies or workload identity labels without developer intervention.

A mutating webhook receives an AdmissionReview request, applies patches via JSON Patch, and returns the modified object. If any mutating webhook rejects the request, the entire API call fails immediately.

These controllers execute after all mutating webhooks complete. They inspect the final object state and either allow or deny the request based on custom policies.

• Image Provenance: Verify that all container images are signed by trusted authorities using Cosign or Notary signatures.
• Resource Constraints: Reject pods that lack defined CPU and memory limits.
• Ingress Rules: Ensure hostnames comply with organizational naming conventions.

Validating webhooks cannot modify objects. They return a simple allowed: true/false response with a human-readable message explaining the denial reason.

Unlike built-in admission plugins compiled into the API server binary, dynamic admission controllers run as external HTTPS services registered via ValidatingWebhookConfiguration or MutatingWebhookConfiguration resources.

• Extensibility: Deploy custom logic in any language without rebuilding Kubernetes.
• TLS Required: All webhook communication must occur over HTTPS with valid certificates.
• Failure Policy: Configure failurePolicy: Ignore or Fail to control behavior when the webhook service is unreachable.

This architecture enables organizations to enforce bespoke security policies, such as validating image signatures against a private container registry before deployment.

A specialized validating admission controller that enforces binary authorization by verifying container image signatures and attestations at deploy time.

• Signature Verification: Checks that images are signed by trusted authorities using Cosign or the Sigstore public good instance.
• Attestation Inspection: Validates SBOMs, vulnerability scan results, and SLSA provenance stored as OCI artifacts.
• Break-Glass Override: Allows authorized users to bypass policy in emergency scenarios with full audit logging.

This webhook integrates directly with private container registries to ensure only approved, tamper-proof images enter production clusters.

Every API request flows through a deterministic admission pipeline before persistence:

1. Authentication: Verify the identity of the caller.
2. Authorization: Check RBAC permissions for the requested verb and resource.
3. Mutating Admission: Apply defaulting and injection logic.
4. Object Schema Validation: Validate the object against the OpenAPI schema.
5. Validating Admission: Enforce custom policies and deny non-compliant requests.
6. Persistence: Write the final object to etcd.

This ordered chain ensures that security policies are applied consistently and transparently to every resource in the cluster.

Kubernetes ships with several built-in admission plugins that are compiled directly into the API server:

• AlwaysPullImages: Mutates every pod to set the image pull policy to Always, ensuring fresh image pulls.
• LimitRanger: Enforces default resource requests and limits on pods and containers.
• PodSecurity: Replaces the deprecated PodSecurityPolicy with a built-in standards-based admission controller.
• ResourceQuota: Ensures that namespaces do not exceed their allocated compute and storage quotas.
• NodeRestriction: Limits the objects a kubelet can modify to its own node.

These built-in controllers execute before any dynamic webhooks and provide foundational cluster security.