Admission Controller

These controllers intercept requests and can modify the object before it is persisted. They execute first in the admission chain, allowing them to inject default values, add sidecar containers, or rewrite pod specifications automatically.

• Execution Order: Run before validating controllers
• Common Use Case: Injecting Istio sidecar proxies into pods
• Idempotency: Must be designed to avoid double-mutation on update operations
• Example: A mutating webhook that automatically adds nodeSelector labels to ensure workloads land on air-gapped GPU nodes

These controllers inspect requests and accept or reject them based on defined policies. They cannot modify the object, only deny it if it violates security rules. They execute after all mutating controllers have finished.

• Binary Decision: Only return Allowed: true or Allowed: false
• Policy Enforcement: Block deployments that use privileged containers or unapproved registries
• Audit Trail: Rejection reasons are logged for compliance
• Example: Denying any pod that attempts to mount a hostPath volume in a disconnected cluster

Webhooks extend the admission chain by calling external HTTP callbacks to evaluate requests. When the API server receives a matching request, it sends an AdmissionReview JSON payload to the configured webhook service and waits for a response.

• MutatingWebhookConfiguration: Registers webhooks that can modify objects
• ValidatingWebhookConfiguration: Registers webhooks that only approve or deny
• Failure Policy: Configurable as Fail (reject if webhook unreachable) or Ignore (allow if unreachable)
• Critical for Air-Gapped Clusters: Webhook services must run locally within the disconnected environment

Kubernetes ships with a set of compiled-in admission controllers that are enabled via the --enable-admission-plugins flag on the API server. These run in-process and do not require external webhook infrastructure.

• AlwaysPullImages: Forces every pod to pull images on restart, preventing stale cached images
• PodSecurity: Replaces the deprecated PodSecurityPolicy with built-in standards (Privileged, Baseline, Restricted)
• ResourceQuota: Enforces namespace-level compute resource limits
• ImagePolicyWebhook: Allows integration with external image scanning tools to validate container signatures before execution

Modern admission control leverages declarative policy languages to define security rules as version-controlled code. Tools like Open Policy Agent (OPA) and Kyverno translate high-level policies into admission decisions.

• Rego Language: OPA's declarative policy language for expressing complex rules
• Kyverno: Kubernetes-native policy engine that uses YAML-based policies without requiring a separate query language
• Supply Chain Security: Policies can verify image signatures and attestations from cosign or Notary
• Example Rule: "All pods in the air-gapped namespace must use images from the local registry registry.internal.local only"

The admission chain follows a strict execution sequence to ensure deterministic behavior. Understanding this ordering is critical for debugging policy conflicts in air-gapped environments where external dependencies are unavailable.

• Sequence: Authentication → Authorization → Mutating Admission → Object Schema Validation → Validating Admission → Persistence to etcd
• Mutating Controllers: Execute in alphabetical order based on their configuration name
• Validating Controllers: Execute in alphabetical order after all mutations complete
• Conflict Resolution: If two mutating controllers modify the same field, the last one wins, which can cause unpredictable results if not carefully designed