What is Kubernetes Admission Controller

Kubernetes Admission Controller Defined

Imagine the Kubernetes API server as the front door to your cluster. Every command you issue, like creating a new Pod or deleting a ConfigMap, goes through this door.

An Admission Controller works like a bouncer just inside that door. It checks every incoming request and decides if it follows the cluster's rules before allowing it in.

If the request is safe and follows the policies, the bouncer lets it through. But if it breaks a rule, like trying to deploy an image from an unapproved registry, the bouncer rejects it right away and sends an error message to the user.

Where Admission Controllers Fit within the Kubernetes API Request Lifecycle

The Kubernetes API request lifecycle has several steps. Admission Controllers come in right after authentication and authorization, but before the object is saved to etcd, the cluster's persistent storage.

Here's a quick overview of the flow:

1. Authentication: The API server verifies the identity of the user or service account making the request.
2. Authorization: The API server checks if the authenticated identity has the necessary permissions (RBAC) to perform the requested action (e.g., creating a Pod).
3. Admission Control: This is when Admission Controllers do their work. It has two sub-phases: Mutating and Validating. This step makes sure the request follows the cluster's policies.
4. Object Persistence: If the request passes all Admission Controllers, the API server writes the new or modified object definition to etcd.
5. Reconciliation: The Kubernetes Controller Manager observes the change in etcd and takes action to match the desired state with the current state (e.g., launching new containers for a Pod).

Since admission control happens after authorization, it can't stop an authorized user from trying an action. But it can block the action if it breaks any policies, it checks the details of the request, not just who made it.

The Difference Between Validating and Mutating Admission Controllers

Admission controllers come in two main types based on what they do:

Mutating Admission Controllers

A mutating admission controller can change an object's configuration on the fly. It takes an incoming resource definition and automatically adds, changes, or rewrites fields before the request moves to the validation phase.

For example, if a developer submits a Deployment manifest without security context settings, a mutating controller can automatically add the runAsNonRoot: true setting to every container in that Pod. This ensures compliance without the developer having to remember it.

Validating Admission Controllers

A validating admission controller acts like a gatekeeper. It can only approve or reject a request and cannot change the resource. If the resource breaks a rule, the controller returns an error, and the object won't be created or updated.

For example, a validating controller might check if a new Service object is exposed to the public internet. If it is and the request doesn't have a special approval label, the controller rejects it to prevent accidental security risks.

The order of execution matters: all mutating controllers run first. Their changes are then seen by the validating controllers that run afterward. This lets you standardize or "clean up" a resource before applying strict validation rules to the final version.

Built-in Admission Controllers Versus Dynamic Admission Controllers

You interact with admission control in two primary ways: the controllers built directly into the API server, and those you deploy yourself.

Built-in Admission Controllers

The Kubernetes API server ships with a set of compiled-in admission controllers that perform essential cluster-level security and operational functions. These are enabled or disabled via configuration flags on the API server.

Examples of built-in controllers include:

• AlwaysPullImages: Enforces that the image pull policy is always Always, improving Kubernetes security by ensuring the latest image is used.
• ResourceQuota: Enforces hard limits on resource consumption per Namespace, preventing one team from consuming all cluster resources.
• PodSecurity: Enforces the Pod Security Standards (PSS), a foundational layer for preventing common container runtime risks.

Dynamic Admission Controllers (Admission Webhooks)

For all your custom, dynamic, and complex policies, you use admission webhooks. These are external services, typically deployed as Pods in your cluster, that the API server calls over HTTP.

When an API request comes in, the API server sends a JSON payload of the resource object to the webhook service. The webhook service evaluates the object against its policies and returns a response:

1. For Mutating Webhooks: The response can contain a "patch" that specifies the changes to be applied to the resource.
2. For Validating Webhooks: The response contains a simple "allowed: true" or "allowed: false," often accompanied by a descriptive message explaining the rejection.

This webhook architecture allows you to write complex, domain-specific policies in any language without modifying the core Kubernetes API server. Tools like Open Policy Agent (OPA) Gatekeeper or Kyverno use this webhook mechanism to provide flexible policy as code capabilities.

Real-World Security Use Cases

Admission controllers are the first line of defense for a production Kubernetes cluster. They enforce constraints that developers, knowingly or unknowingly, might miss.

Use Case	Controller Type	Description
Blocking Privileged Containers	Validating	Rejects any Pod where privileged: true is set, a critical security control to prevent container breakout.
Requiring Corporate Labels/Annotations	Validating	Ensures all resources (e.g., Deployments, Services) have mandatory labels for tracking ownership, cost allocation, or security level (e.g., environment: production).
Restricting Image Sources	Validating	Prevents the use of container images from public, unapproved registries like Docker Hub and enforces usage of an internal, scanned registry.
Injecting Sidecar Containers	Mutating	Automatically injects security agents (e.g., logging agents, security monitoring sidecars) into every new Pod, standardizing security tooling.
Enforcing Read-Only Root Filesystems	Mutating	Modifies the Pod security context to set readOnlyRootFilesystem: true, mitigating risks if an attacker gains shell access.
Volume Type Restriction	Validating	Blocks the use of sensitive or legacy volume types (e.g., hostPath volumes) that could compromise the node or its file system.

How Admission Controllers Support Policy as Code and DevSecOps Practices

Admission controllers play a key role in enabling Policy as Code (PaC) in Kubernetes. PaC means security and compliance rules are written in machine-readable formats like YAML, JSON, or Rego, and enforced automatically instead of depending on manual checks or documents.

Using dynamic admission controllers (webhooks), security teams can:

1. Shift Left: Policies are evaluated at deployment time, immediately providing feedback to the engineer. This is the essence of DevSecOps, identifying and fixing security issues before they hit the cluster.
2. Centralize Governance: Policies are maintained in a central repository (e.g., Git) and deployed across all clusters, ensuring consistency.
3. Audit and Visibility: The policies themselves become auditable artifacts, allowing teams to prove compliance with internal or external regulations.

This shift moves security from a gate at the end of the pipeline to a core, integrated part of the deployment process, significantly enhancing Kubernetes security posture.

Common Misconfigurations and Security Risks

Admission controllers are essential, but if they are misconfigured, they can cause serious risks and operational headaches.

Operational Risks

• Webhook Failure or Timeouts: If a dynamic admission webhook is set up incorrectly, gets overloaded, or fails, it can block all API requests to the cluster and make it unusable. That's why webhooks have failure policies like Ignore or Fail, which need to be set up carefully.
• Order Dependencies: If mutating webhooks are not executed in the correct order, one webhook might overwrite the critical changes made by another, leading to unexpected resource states.

Security Risks

• Scope Misconfiguration: A webhook with the wrong scope might apply strict policies to resources it shouldn't, or fail to enforce important policies on sensitive resources.
• Incomplete Validation Logic: Security policies need to be thorough. A common error is validating only the Deployment object but missing the Pod spec, which attackers could exploit through template overrides.
• Bypassing the Controller: If an attacker finds a way to communicate directly with etcd or bypass the API server entirely, the admission controller is useless. This is why layered defense is essential.

What Happens Without Admission Controllers: Real Attack Paths

The consequences of missing or misconfigured admission controls become concrete when examining real attack chains against Kubernetes clusters.

Pod Creation as a Privilege Escalation Vector

One of the most dangerous RBAC permissions an attacker can discover is the ability to create pods in a namespace. Unlike read-only permissions that limit an attacker to reconnaissance, pod creation grants control over the execution context of new workloads, including which service account those workloads run under.

In documented attack chains against EKS clusters, attackers who compromised a web application through server-side code injection used the compromised pod's service account to enumerate RBAC permissions with kubectl auth can-i --list. When that enumeration revealed pod creation rights in a different namespace, the attacker deployed a new pod bound to a service account with IRSA (IAM Roles for Service Accounts) annotations. This gave the attacker's pod AWS credentials tied to an elevated IAM role, enabling them to assume additional roles and exfiltrate sensitive data from DynamoDB.

The entire escalation path, from application compromise to cloud data exfiltration, relied on the absence of admission controls at two points:

1. No restriction on cross-namespace pod creation: An admission controller enforcing the restricted Pod Security Standard would have blocked the attacker from creating pods with an alternate service account or elevated security context.
2. No validation of service account binding: A policy engine like Kyverno or OPA Gatekeeper could enforce that pods in a given namespace may only reference pre-approved service accounts, preventing an attacker from inheriting IRSA-mapped cloud credentials.

Cross-Namespace Movement Without Controls

Without admission controllers, RBAC is the only barrier between namespaces. But RBAC alone answers "can this identity perform this action?" without examining the content of the request. An authorized identity with create permissions can submit any valid pod specification, including those that mount host paths, run privileged containers, or reference service accounts with cloud provider integrations. Admission controllers close this gap by inspecting the request payload and rejecting specifications that violate security policy, regardless of who submitted them.

Best Practices for Implementing Admission Controllers Securely

Implementing admission control well takes careful planning and attention. These best practices will help you boost security while keeping your cluster stable.

1. Test Thoroughly and in Staging Environments

Never deploy a new admission webhook directly to production. Use a dedicated staging cluster to test the policy against real workloads and ensure it doesn't break existing deployments or critical system functions.

2. Set Appropriate FailurePolicy

For non-critical policies, set failurePolicy to Ignore so the API server lets requests through if the webhook service fails. For important security policies, like blocking privileged containers, set failurePolicy to Fail. Keep in mind the trade-off between stability and security enforcement.

3. Minimize the Scope

Use scope and rules within your ValidatingWebhookConfiguration or MutatingWebhookConfiguration to target only the specific resources and namespaces that need policy enforcement. For instance, exclude the kube-system namespace from most custom policies to avoid breaking core Kubernetes components.

4. Use Policy Engines (e.g., OPA Gatekeeper, Kyverno)

Rather than building custom webhooks from scratch, use established policy engines. These tools offer a standard language (Rego for OPA, YAML for Kyverno), strong audit features, and community support, which makes managing policy as code easier.

5. Sign and Verify Webhook Certificates

Ensure secure communication between the Kubernetes API server and your webhook service by using TLS and verifying the certificates. This prevents man-in-the-middle attacks where an attacker could impersonate the policy server.

Related Labs

See admission controller security concepts in action through hands-on attack and defense labs:

• Escalate from SSJI to EKS - Exploit server-side JavaScript injection to gain pod access, then abuse RBAC pod creation permissions and IRSA role chaining to escalate from application compromise to AWS data exfiltration, demonstrating exactly what admission controllers are designed to prevent.
• Secure Kubernetes using OPA Gatekeeper - Implement and configure OPA Gatekeeper admission controller policies to enforce pod security standards, restrict privileged containers, and prevent the misconfigurations that enable privilege escalation.

Frequently Asked Questions

What is an admission webhook?

An admission webhook is a mechanism used to implement a dynamic admission controller. It is an external HTTP service that the Kubernetes API server queries to validate or mutate a resource request before persistence. It allows for complex, external policy logic.

Why are Kubernetes Admission Controllers important for security?

They are the most powerful control point for Kubernetes security because they provide the last opportunity to enforce policies on the content of a resource definition. They ensure that no insecure, non-compliant, or potentially malicious resources are ever written to the cluster's persistent store (etcd).

What is the primary function of a mutating admission controller?

The primary function of a mutating admission controller is to modify or inject configuration into a resource request. This is commonly used for standardization, such as automatically adding required labels, security contexts, or sidecar containers to maintain compliance.

How do admission controllers relate to DevSecOps?

Admission controllers enable the "shift left" principle in DevSecOps by enforcing policy enforcement in Kubernetes at deployment time. If a policy violation occurs, the user immediately receives feedback, allowing them to fix the security issue without waiting for a post-deployment audit.

How is an admission controller different from RBAC?

RBAC (Role Based Access Control) controls who can perform an action (Authorization), based on their identity and permissions. An Admission Controller controls what the authorized person is trying to do, based on the content and structure of the resource object. They are complementary layers of Kubernetes security.