How Kubernetes Admission Controllers Work: The Hidden Gatekeepers
Admission controllers do not inspect container images; they evaluate the metadata and permissions of the object before it is persisted to the cluster storage.
Admission controllers intercept API requests before objects are stored. They validate or mutate the request using webhooks or built-in rules. This occurs after authentication but before persistence, allowing you to enforce policy or modify object specifications dynamically.
The Admission Pipeline Architecture
Kubernetes operates as a REST API server. Every change to the cluster state, from creating a pod to deleting a namespace, arrives as an HTTP request. Before the API server writes this change to etcd, the storage backend, it passes through an admission control pipeline. This pipeline acts as a series of checkpoints.
You might assume that admission controllers scan container images for vulnerabilities. They do not. They inspect the manifest describing the object. If you request a pod that runs as root, the controller sees the securityContext field in the JSON payload. It does not look inside the image layer.
This distinction matters because it defines the scope of protection. The pipeline ensures that the cluster state remains consistent with your policies. It does not protect the runtime environment from exploits within the container itself. For deeper runtime insights, you would look to cloud detection and response tools.
### Stage 1: Authentication and Authorization
The pipeline begins before admission control proper. The API server first verifies who is making the request. It checks the certificate, token, or identity provider assertion. If the identity is invalid, the request fails immediately.
Next, the server determines what that identity is allowed to do. This is authorization. It checks Role-Based Access Control rules. If a user lacks permission to create pods in a specific namespace, the request is rejected here.
Admission controllers never see requests that fail this stage. This creates a hidden dependency. If your identity management is weak, admission controls are bypassed entirely. Identity sprawl can create gaps where service accounts retain excessive permissions, rendering admission policies ineffective.
### Stage 2: Webhook Preparation
Once the request is authorised, the API server prepares it for admission. It determines which admission plugins are relevant. Some plugins are built into the API server binary. Others are external webhooks.
For external webhooks, the API server must locate the endpoint. It reads the configuration from the cluster’s AdmissionRegistration resources. These resources define the service name, namespace, and TLS certificate for the webhook server.
This step introduces a network dependency. The API server must be able to reach the webhook endpoint. If the network is partitioned or the endpoint is slow, the API request hangs. You must design for failure. If the webhook is unavailable, the API server may reject the request by default, causing outages.
### Stage 3: Mutating Admission Controllers
Mutating controllers run first. They can modify the object being created or updated. They add labels, set default resource limits, or enforce security contexts. They can also inject sidecar containers for monitoring or logging.
Imagine a developer submits a pod definition without resource limits. A mutating controller intercepts this. It injects default CPU and memory limits before the object is stored. The developer never sees this change. The object appears as if they defined it correctly.
This power is dangerous. A misconfigured mutating controller can break applications by adding incompatible fields. It can also be used to bypass security by stripping security contexts. Always audit mutating rules carefully. They operate silently and change the truth of your cluster state. See Kubernetes misconfigurations for common pitfalls.
### Stage 4: Validating Admission Controllers
Validating controllers run after mutating ones. They cannot change the object. They can only accept or reject it. They check the final state of the object against policy rules.
If a pod requests privileged mode, a validating controller can block it. It returns an error message to the client. The request fails. The object is not stored. This is the primary defence against policy violations.
Validating controllers are stateless. They do not remember previous requests. Each request is evaluated independently. This makes them reliable but limited. They cannot enforce complex, stateful policies like "only one privileged pod per namespace" without external state.
See also: How Misconfigured IAM Roles Work: The Step-by-Step Attack Path · CSPM vs CWPP: How to Choose Cloud Security Tools
### Stage 5: Persistence and Final Admission
If all controllers accept the request, the API server writes the object to etcd. This is the point of no return. The object now exists in the cluster. Controllers like LimitRanger and ResourceQuota run here to ensure cluster-wide limits are not exceeded.
These final checks are critical for stability. They prevent resource exhaustion. If a namespace exceeds its quota, the creation fails. This protects the cluster from noisy neighbours.
However, these checks are basic. They do not inspect the content of the payload for malicious code. They only check resource counts. For true security, you need more than quotas. You need least privilege in the cloud principles applied to every service account.
| Stage | What happens | Where it can be stopped |
|---|---|---|
| Authentication | Identity verification | Invalid credentials |
| Authorization | Permission check | Insufficient RBAC rights |
| Mutating Admission | Object modification | Webhook timeout or error |
| Validating Admission | Policy enforcement | Policy violation |
| Persistence | Storage in etcd | Resource quota exceeded |
The Limits of Admission Control
Admission controllers are powerful but limited. They only see the API request. They do not see the runtime behaviour. A pod can be created with perfect policy compliance and then execute malicious code.
They also depend on the API server. If an attacker gains direct access to etcd, they bypass admission controls entirely. This is why securing the control plane is vital. You must also consider cloud logging gaps to ensure you can detect such bypasses.
Another limit is complexity. Managing many webhooks increases latency. Each webhook adds round-trip time to every API call. In large clusters, this can degrade performance. You must balance security with usability.
Finally, admission controllers do not manage secrets. They cannot encrypt sensitive data at rest. You need dedicated secrets managers for that. Admission can enforce that secrets are used, but not that they are safe.
Designing for Failure
When designing admission controls, assume they will fail. Network partitions, certificate expirations, and bugs are inevitable. You must define failure policies.
For validating webhooks, the default is often to fail closed. This means the request is rejected if the webhook is unreachable. This is secure but disruptive. For mutating webhooks, failing open might be necessary to maintain availability, but this risks policy violations.
You must test these scenarios. Simulate webhook outages. Ensure your cluster remains stable. Monitor the health of your admission endpoints. Use cloud landing zones to standardise this configuration across environments.
Key takeaways
- Validating controllers reject requests that violate policy but cannot alter them.
- Mutating controllers can rewrite object specifications, changing security contexts or adding labels.
- The admission stage is separate from authentication, meaning identity verification happens first.
Admission controllers enforce policy at the API boundary, not the runtime. Audit your webhook configurations and failure modes regularly to prevent outages and policy bypasses.
Frequently asked questions
Can admission controllers prevent container escapes?
No. They validate the request metadata, not the runtime behaviour. They cannot stop exploits that occur after the container is running.
Do admission controllers slow down deployments?
Yes. Each webhook adds network latency. Excessive or slow webhooks can significantly delay API responses and user interactions.
What happens if a mutating webhook fails?
It depends on the failure policy. If set to Fail, the request is rejected. If set to Ignore, the object is created without the mutation, potentially violating policy.
Can admission controllers be bypassed?
Yes. Direct access to etcd, compromised API servers, or misconfigured RBAC can bypass admission controls entirely.
How this guide was produced: written by the Packet Tribune editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
