Admission Controllers

In one line

An admission controller intercepts every request to the API server AFTER authentication and authorization but BEFORE it's actually persisted — the layer that can automatically validate or even modify a resource before it ever takes effect.

0/4 · 0%

Think of it like this

A building's final security check right before someone actually enters a restricted area — even after their keycard (RBAC, Topic 5.1) has already been verified as valid, a guard might still do one more check (is this bag allowed in here?) or even hand them a visitor badge automatically (a modification) before actually letting them through.

Key ideas

01
Every request to the API server passes through several stages in order: AUTHENTICATION (who are you), AUTHORIZATION (RBAC — are you allowed to do this action), and then ADMISSION CONTROL (a final set of checks and possible modifications) — only after successfully passing ALL THREE does a request actually get persisted to etcd and take effect.
02
A VALIDATING admission webhook can APPROVE or REJECT a request outright based on custom logic — the Pod Security Standards from Topic 5.2 are actually implemented as a built-in validating admission mechanism; the example there (rejecting a pod for violating restricted) is admission control happening directly, even though that topic didn't yet name it as such.
03
A MUTATING admission webhook can actually MODIFY a request before it's persisted — a genuinely common real example: automatically INJECTING a sidecar container into every pod matching certain labels (a service mesh's proxy, Phase 8, is commonly injected this exact way), without every single developer needing to remember to add that sidecar to their own manifests manually.
04
Two popular POLICY ENGINES — Open Policy Agent (with its Gatekeeper admission controller) and Kyverno — let teams write custom admission rules WITHOUT needing to build and host a full custom webhook service themselves: 'reject any pod that doesn't specify resource limits,' 'require every image to come from our approved internal registry,' or 'reject any Deployment missing a required label' are all genuinely realistic, common real policies enforced this way.
05
This is Kubernetes' own equivalent of Linux's 'default deny, then explicitly allow' firewall philosophy and Git's branch-protection required-status-checks, applied at the API level itself — admission control is what makes an organizational POLICY (not just a technical capability) genuinely, automatically enforced, rather than merely documented somewhere and hoped to be followed.

Code & diagrams

AdmissionControlFlowdiagram

Three gates, in order — a request must pass all three before it actually takes effect.

Rendering diagram…

kyverno-policy.yamlmarkdown

A realistic, common policy — no custom webhook code needed at all.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-limits
spec:
  validationFailureAction: Enforce   # actually block, don't just warn
  rules:
    - name: check-limits
      match:
        resources:
          kinds: ["Pod"]
      validate:
        message: "Every container must specify CPU and memory limits."
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    cpu: "?*"
                    memory: "?*"

admission-control.shmarkdown

Confirm a policy actually blocks a non-compliant resource at admission time.

kubectl apply -f kyverno-policy.yaml

# Try creating a pod with NO resource limits — should be rejected outright
kubectl run no-limits-pod --image=nginx
# Error: admission webhook "validate.kyverno.svc" denied the request:
# Every container must specify CPU and memory limits.

# A compliant pod passes through normally
kubectl run compliant-pod --image=nginx --limits="cpu=200m,memory=256Mi"
kubectl get pod compliant-pod
# Running — passed admission control successfully

Explain it without notes

Where does admission control sit in the overall request lifecycle, relative to authentication and authorization (RBAC)?

Why would a team use a policy engine like Kyverno or OPA/Gatekeeper instead of building their own custom admission webhook from scratch?

Practice

If you have Kyverno or OPA/Gatekeeper available on a test cluster, apply the example policy and confirm a pod without resource limits is genuinely rejected, while a compliant one succeeds.

Think of one real policy your own team (or a hypothetical one) would benefit from enforcing automatically (e.g., 'every image must come from our internal registry,' 'every Deployment must have an owner label') and sketch, in plain English, what a Kyverno rule for it would need to check.

Trade-offs

↔
Admission control genuinely enforces policy automatically and consistently, removing reliance on manual review or documentation alone — but an overly strict or buggy admission policy can block LEGITIMATE requests cluster-wide (a validating webhook that's misconfigured, or unreachable, can bring deployments to a halt entirely) — this is exactly why admission webhooks typically support a failurePolicy setting (fail open vs fail closed) that needs genuine, deliberate thought about which failure mode is actually safer for a given policy's specific purpose.

Done when you can

I understand admission control is the final stage of the request lifecycle, after authentication and RBAC authorization.
I can explain the difference between a validating and a mutating admission webhook.
I know policy engines like Kyverno/OPA exist specifically to avoid writing custom admission webhook code for common policies.