Skip to main content
RBAC (Role-Based Access Control) controls who (which users or service accounts) may perform actions on Kubernetes resource types, but it cannot inspect or enforce the actual configuration of those resources. For example, RBAC can allow Alice to create Deployments, but it cannot require that Alice’s Deployments include resource limits or disallow privileged containers. Admission control closes that gap by inspecting — and optionally modifying — objects as they are submitted to the API server. In this lesson you’ll learn:
  • Where admission controllers sit in the Kubernetes API request flow.
  • The difference between mutating and validating webhooks.
  • How Gatekeeper and Kyverno implement policy and when to choose each.
What can go wrong without admission control A gaming company had strict RBAC: developers could only create resources in their own namespaces. Still, a developer created a Pod to debug networking with securityContext.privileged: true and hostNetwork: true. That Pod had full access to the host network stack and other containers on the node. An attacker exploited a vulnerability in the debug container and escaped the container. RBAC could not prevent this because it does not inspect Pod specs.
An illustration showing a hooded attacker pointing at a large game-controller graphic labeled "Own Namespace" that represents a "Pod with Privilege." To the right are boxes labeled "Network Stack" and "Other Containers" and a person at a computer with "GAME OVER," depicting a privileged pod (true and hostNetwork: true) compromise.
RBAC says who can create Pods. Admission control says which Pod configurations are allowed. RBAC cannot tell you whether:
  • A container runs as root,
  • An image is from an untrusted registry,
  • Resource requests/limits are missing,
  • A container is privileged,
  • Required labels are present on new objects.
Admission controllers inspect the object configuration and can either reject objects that violate policy or mutate them to comply with platform standards.
An infographic titled "The Gap RBAC Leaves" that contrasts RBAC (who can create resources) with admission control (which configurations are allowed). It shows red warning boxes listing security gaps like "Container runs as root," "Image from untrusted registry," "Missing resource limits," "Privileged container," and "Missing required labels."
Where admission control fits in the API request flow Kubernetes processes API requests in a defined sequence. The order is important because some stages mutate objects and later stages must evaluate those mutations.
  1. Authentication — Who are you?
  2. Authorization (RBAC) — Are you allowed to perform this action?
  3. Mutating admission webhooks — Can change the incoming object (first to run).
  4. Schema validation and built-in admission controllers.
  5. Validating admission webhooks — Accept or reject the (possibly mutated) object.
  6. Persist to etcd — Only after all checks pass.
Mutating webhooks run before validating webhooks so that any injected defaults or changes are subject to validation.
A flowchart titled "Where Admission Control Sits" showing the stages of Kubernetes admission control: Authentication, Authorization, Mutating Webhooks, Schema Validation, Validating Webhook, and Persist. Each step is shown as a labeled box with an icon and a short question (e.g., "Who is this?", "Is the YAML valid?").
Mutating webhooks can inject defaults, sidecars, or labels before validation. Always design mutating rules with the validating rules in mind so validation evaluates the object that will actually be persisted.
Mutating vs. Validating webhooks
  • Mutating webhooks
    • Can modify the incoming object.
    • Common uses: inject sidecars (logging, service mesh proxies), add default labels/annotations, set default resource requests/limits when omitted.
  • Validating webhooks
    • Cannot modify objects; they accept or reject them.
    • Common uses: block privileged containers, enforce allowed registries, require specific labels, reject Pods that run as root.
Kyverno supports both mutation and validation. Gatekeeper (OPA Gatekeeper) provides validating-only functionality.
An infographic titled "Mutating vs Validating Webhooks" showing two columns: the red left column lists examples of mutating webhooks (inject sidecars, add default labels/resources, set tolerations, inject env vars) and the green right column lists validating webhook checks (block privileged containers, require approved registries, enforce resource limits, reject pods running as root).
Six practical policies that cover most platform needs A small set of well-designed policies will address the bulk of platform safety and governance: Example field condition that enforces no privileged containers:
Gatekeeper vs. Kyverno — differences at a glance Both Gatekeeper (OPA Gatekeeper) and Kyverno extend the Kubernetes admission framework, but they differ in language, architecture, and capabilities. Many teams run both tools to leverage Gatekeeper’s expressiveness for advanced checks and Kyverno’s ease for mutation and common validations. Both tools are included in cloud-native platform certification exam lists.
An infographic comparing the OPA Gatekeeper and Kyverno policy engines side-by-side, showing language, architecture, type, strengths, and exam weight. The Gatekeeper side highlights Rego and a validating-only webhook, while Kyverno emphasizes Kubernetes YAML and both mutating and validating capabilities.
Built-in admission controllers Kubernetes includes a set of built-in admission controllers that are compiled into the API server and run automatically. These controllers handle many default behaviors and basic validations.
A presentation slide titled "Built-In Admission Controllers" listing five Kubernetes controllers with brief descriptions. The controllers shown are NamespaceLifecycle (Validate), LimitRanger (Mutate), ResourceQuota (Validate), ServiceAccount (Mutate), and PodSecurity (Validate).
Best practices and final notes
  • Apply a few high-value validating policies first (image registry whitelist, required labels, no privileged containers, resource limits). These block the most common and risky misconfigurations.
  • Use mutating webhooks to enforce defaults and reduce developer friction (inject labels, annotations, or sidecars).
  • Test policies in dry-run or audit mode before enforcement to avoid surprising teams. Both Gatekeeper and Kyverno support dry-run modes.
  • Keep policy logic simple and well-documented. Complex Rego can be powerful but harder to maintain; Kyverno’s YAML rules are easier to read for Kubernetes operators.
Admission control is a safety net, not a substitute for secure container images, least-privilege RBAC, or host hardening. Combine RBAC, admission controls, image scanning, and runtime defenses for a layered security posture.
References and further reading

Watch Video