Topic 36

Admission Control and Policy

PolicyAdmission

After a request is authenticated and authorized, it passes through admission controllers — code that can inspect, modify, or reject the object before it is stored. This is where organization-specific rules live: require a label, block a risky setting, inject a sidecar, restrict image sources.

Admission is the most powerful customization point in the API, and the one that can take the cluster down if misused. Understanding mutating vs validating admission, and the failure modes, is essential before you rely on it.

Where Admission Runs

Admission is the third gate, after authentication and authorization and just before persistence. There are built-in admission controllers (enabled in the API server) and dynamic ones you add via webhooks. The order matters: mutating admission runs first and can change the object, then validating admission runs and can only accept or reject. By the time validation runs, it sees the object as it will be stored.

Mutating vs Validating Webhooks

A MutatingAdmissionWebhook can alter an incoming object — inject a sidecar, add default labels, set a securityContext. A ValidatingAdmissionWebhook can only approve or deny — enforce that a label exists, reject a privileged Pod, require resource limits. Mutation is powerful and surprising (objects differ from what was submitted), so prefer validation when you only need to enforce, and reserve mutation for genuine defaulting and injection.

Policy Engines

Writing webhook servers by hand is tedious, so policy is usually delegated to an engine. OPA/Gatekeeper expresses policy in Rego and ships as a validating (and mutating) webhook with a library of constraints. Kyverno expresses policy as Kubernetes-native YAML, which many teams find easier. Both enforce rules like "images only from our registry," "every namespace needs an owner label," or "no :latest tags" at admission time, cluster-wide.

In-Tree Policy and Failure Modes

Kubernetes also has a built-in, webhook-free option: ValidatingAdmissionPolicy, which expresses validation in CEL and runs inside the API server — no external server to operate or to fail. The great danger of webhook-based admission is failurePolicy: Fail: if the webhook server is down and the policy fails closed, it can block all matching API operations — including, in the worst case, the very Pods needed to bring the webhook back. Scope webhooks narrowly, exclude system namespaces, and consider in-tree CEL policies to avoid the external dependency.

Webhook policy engine vs in-tree ValidatingAdmissionPolicy

Webhook engine (Gatekeeper/Kyverno) — rich and flexible, but an external server you must run and that can fail closed.

ValidatingAdmissionPolicy (CEL) — built into the API server, no external dependency; less expressive but no server to take down the cluster.

Common Mistakes

Setting failurePolicy: Fail on a broad webhook, so an outage of the webhook server blocks the whole API.
Using mutating admission where validation would do, leaving stored objects different from what was submitted.
Failing to exclude system namespaces from a webhook, risking a deadlock where the cluster can't recover.
Hand-writing webhook servers instead of using a maintained policy engine.
No image-source or required-field policy, leaving organization rules unenforced.

Best Practices

Prefer validating over mutating admission; reserve mutation for genuine defaulting and injection.
Use a policy engine (Gatekeeper or Kyverno) or in-tree ValidatingAdmissionPolicy rather than bespoke webhooks.
Scope webhooks narrowly and exclude kube-system to avoid lockouts.
Think hard about failurePolicy — failing closed protects policy but can take down the API.
Enforce key rules at admission: trusted image sources, required labels, no :latest, resource limits present.

RelatedAuthentication & authorization — the gates before admission (Topic 31)Pod Security Standards — a built-in admission case (Topic 34)Supply-chain security — image policy enforced at admission (Topic 37)

Knowledge Check

What is the difference between mutating and validating admission?

Mutating can change the object (runs first); validating can only accept or reject (runs after)
Validating runs first and patches the object; mutating runs afterward and only admits or denies
They are the same phase; the two names are fully interchangeable in the config
Mutating only applies to Secrets; validating only applies to ConfigMaps

Why is failurePolicy: Fail on a broad admission webhook dangerous?

If the webhook server is down, it can block all matching API operations — potentially deadlocking recovery
It adds a fixed timeout to every matching request and makes the whole API server measurably slower under load
It disables authentication for any request the webhook happens to match while it is unreachable
It forces every matching Pod to run as privileged once the webhook stops responding

What advantage does ValidatingAdmissionPolicy (CEL) have over a webhook policy engine?

It runs inside the API server with no external server to operate or fail
Its CEL expressions are more expressive than the code a webhook runs
It can mutate objects in place, which validating webhooks are never able to do
It requires no policy definitions and applies a built-in default rule set

You got correct