Admission Controllers in Kubernetes

When you interact with a Kubernetes cluster — say by creating a Pod, Service, or Deployment — your request passes through a series of steps before the object is stored in etcd and becomes active in the cluster.

An Admission Controller is a piece of code that intercepts (mutates or validates) API requests after authentication and authorization, but before the object is persisted in etcd.

In simple terms:
They act like a checkpoint — enforcing policies and performing automatic modifications on Kubernetes objects at creation or update time.

Where Admission Controllers Fit in the API Request Flow

Here’s a simplified request lifecycle in Kubernetes:

kubectl apply -f pod.yaml

Authentication → Authorization → Admission Controllers → etcd

Admission Controllers are executed sequentially, and they can either:

• Mutate the request (e.g., add a label, inject sidecar containers)

• Validate the request (e.g., deny pods using hostPath volumes)

Types of Admission Controllers

1. Mutating Admission Webhooks

These can modify the object in the incoming request.
Used for auto-injection (e.g., Istio sidecars), setting default values, etc.

2. Validating Admission Webhooks

These cannot change the object — they only accept or reject the request.
Used for policy enforcement, like blocking privileged containers.

You can chain both: first mutating webhooks run, then validating ones.

Built-In Admission Controllers

Kubernetes ships with several built-in controllers. Some common ones:

To see the enabled admission plugins on your cluster:

kubectl get --raw /configz | jq .admissionControl
or
ps -ef | grep "admission-plugins"

Or check the --enable-admission-plugins flag on the API server.

Real-World Use Cases

Inject Sidecars Automatically

Tools like Istio, Linkerd, or Vault Agent Injector use mutating webhooks to inject containers into pods dynamically.

Enforce Security Policies

You can use OPA/Gatekeeper or Kyverno to write policies like:

• Prevent use of hostNetwork

• Require labels on all deployments

• Allow only certain container registries

Control Resource Usage

Ensure every pod has CPU/memory requests and limits via the LimitRanger controller.

Configuring Admission Controllers

For Mutating Webhooks:

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  name: example-mutating-webhook
webhooks:
  - name: mutate.example.com
    rules:
      - apiGroups: ["*"]
        apiVersions: ["v1"]
        operations: ["CREATE"]
        resources: ["pods"]
    clientConfig:
      service:
        name: webhook-service
        namespace: default
        path: "/mutate"
      caBundle: <base64-encoded-ca>

You can write the webhook logic as a separate HTTP server (e.g., using Go or Python) that receives admission requests and returns patches or validation responses.