Kubernetes Admission Controllers: Enforce Policy Before Workloads Start
Admission controllers intercept API requests before persistence, allowing you to reject non-compliant configurations before they ever touch the cluster storage layer.
Kubernetes admission controllers act as gatekeepers that inspect and modify resource requests before they are stored. They enforce security policies, such as blocking privileged containers or injecting sidecar proxies. You configure them via webhook endpoints or built-in plugins to ensure every workload meets your operational and security standards before deployment.
How Kubernetes Admission Controllers Function
Kubernetes admission controllers are modules that intercept requests sent to the API server before any object is persisted in etcd. They operate in two distinct phases: mutation and validation. Mutating admission controllers modify the request object, such as adding default labels or injecting sidecar containers. Validating admission controllers inspect the modified object and reject it if it violates policy rules. This sequence ensures that only compliant resources enter the cluster state.
The API server processes these controllers in a fixed order. Built-in controllers run first, followed by external webhook controllers. This order matters because a mutating webhook can change an object in a way that a subsequent validating webhook then rejects. You must understand this chain to debug policy failures. If a controller rejects a request, the API server returns an error to the user immediately. The object never reaches the underlying storage system.
| Aspect | Detail |
|---|---|
| Execution Order | Mutating controllers run before validating controllers. |
| Scope | Applied to all resource creation, update, and deletion requests. |
| Failure Mode | Failed webhook calls can block cluster operations depending on configuration. |
| Configuration | Managed via APIService objects and ValidatingWebhookConfiguration resources. |
| Persistence | Changes are applied before the object is saved to etcd. |
The Two Types of Admission Control
Mutating admission controllers change the resource specification before validation. They are often used for automation tasks that reduce manual configuration effort. For example, a mutating controller can automatically add a default image pull secret to every pod specification. This ensures that all containers can pull images without requiring developers to specify credentials manually. This reduces configuration drift and human error across large teams.
Validating admission controllers check the final state of the resource. They do not modify the object. They simply accept or reject it based on predefined rules. A validating controller might check that no container runs as the root user. If the request specifies runAsUser: 0, the controller rejects it. This enforces least-privilege principles at the infrastructure level. You cannot bypass these checks through standard API interactions. They provide a hard boundary for security compliance.
Dynamic Admission Control via Webhooks
External admission controllers run as independent services and communicate with the API server via HTTPS webhooks. This architecture allows you to write policy logic in any programming language. You deploy the controller as a separate application in the cluster. The API server calls your webhook endpoint for every relevant request. This decoupling means you can update policy logic without restarting the API server or modifying core Kubernetes components.
The API server must trust the webhook’s TLS certificate. You must configure the caBundle in the webhook configuration resource. If the certificate expires or becomes invalid, the API server cannot verify the webhook’s response. This often results in the API server rejecting all requests that trigger the webhook. This failure mode can lock out cluster access entirely. You must monitor certificate validity and automate renewal processes to prevent operational outages.
Configuring Webhook Failure Policies
You must define how the API server behaves when a webhook fails to respond. The failurePolicy setting determines this behavior. If set to Fail, the API server rejects the request when the webhook is unreachable. This provides strong security guarantees but introduces operational risk. If the webhook service goes down, users cannot create or update resources. This can halt deployment pipelines and emergency incident response.
If set to Ignore, the API server accepts the request if the webhook is unreachable. This ensures availability but creates security gaps. Non-compliant resources may enter the cluster during webhook outages. You typically choose Fail for production workloads where security is paramount. You might choose Ignore for non-critical environments or during initial testing. Consider using sideEffects annotations to tell the API server if the webhook modifies state, which affects retry logic.
Common Misconfigurations and Pitfalls
Many teams underestimate the performance impact of admission controllers. Each webhook call adds latency to every API request. If your webhook performs complex computations or calls external databases, cluster operations slow down. High-latency webhooks can cause timeouts for users interacting with the dashboard or command line. You should optimize webhook logic for speed and cache results where possible. Keep the critical path minimal to maintain cluster responsiveness.
Another frequent mistake is applying global policies to all namespaces. This lacks granularity and causes friction for legitimate use cases. Different teams may have different security requirements. Use namespace-scoped labels or annotations to tailor policies. This allows development teams to test with relaxed rules while enforcing strict controls in production. Proper scoping reduces alert fatigue and policy bypass attempts.
See also: Firewalls in Cloud Computing: How They Work and Where They Fail · What Does DevSecOps Mean: Integrating Security Into The Software Pipeline
Integrating with Broader Security Architectures
Admission controllers work best when combined with other security layers. They enforce policy at entry but do not monitor runtime behavior. You should pair them with cloud workload protection platforms that detect anomalies after deployment. Admission controllers stop bad configurations; runtime protection stops bad behavior. This defense-in-depth approach covers the entire lifecycle of a workload.
Identity management also plays a role. Admission controllers can validate service accounts and roles. You should align admission policies with Kubernetes RBAC to ensure that only authorized users can deploy sensitive workloads. Additionally, consider how these policies interact with zero trust network access strategies. While admission controllers handle pod creation, network policies and zero trust principles govern traffic flow between those pods. Both mechanisms are necessary for a secure environment.
What People Usually Get Wrong
Teams often treat admission controllers as a set-and-forget solution. They deploy a policy engine and assume compliance. They fail to test the policies against actual application manifests. This leads to false positives that block legitimate deployments. You must integrate policy testing into your CI/CD pipeline. Simulate admission controller checks during the build phase. This catches violations before they reach the cluster API server.
Another misconception is that admission controllers replace configuration management. They do not manage the state of running resources. They only control new or modified resources. Existing non-compliant resources remain untouched until they are updated. You must use separate scanning tools to identify and remediate legacy workloads. Admission controllers prevent new debt; they do not erase old debt.
Key takeaways
- Admission controllers intercept API server requests before object persistence.
- Validating controllers reject non-compliant resources while mutating controllers modify them.
- Misconfigured webhooks can block all cluster operations if the endpoint becomes unreachable.
- Dynamic admission control allows real-time policy enforcement without cluster restarts.
Admission controllers provide the only reliable mechanism to enforce policy before resources are persisted in the cluster state. Audit your webhook configurations and test failure scenarios to prevent accidental cluster lockouts during maintenance or outages.
Frequently asked questions
Can admission controllers protect against runtime exploits?
No, admission controllers only evaluate requests before resources are created or updated. They cannot detect or stop malicious activity in already running containers. You need runtime security solutions for that protection.
How do admission controllers differ from Kubernetes RBAC?
RBAC controls who can make API requests and what actions they can perform. Admission controllers control what those requests can contain. RBAC is about identity and permission; admission control is about configuration compliance and content.
What happens if a mutating webhook times out?
The behavior depends on the configured `timeoutSeconds`. If the webhook does not respond within this window, the API server follows the `failurePolicy`. It either rejects the request or ignores the webhook’s input, depending on your security and availability priorities.
Do admission controllers work with all Kubernetes resources?
They work with most namespaced and cluster-scoped resources. You configure the webhook to target specific APIs, such as pods, deployments, or network policies. You can exclude certain resources or namespaces if they require different handling or testing flexibility.
How this guide was produced: written by the Firewall Scoop 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.
