What Is Admission Controllers? Security Definition
Also known as: admission controllers, Kubernetes admission controllers, CKS exam, admission webhooks, PodSecurity
On This Page
Quick Definition
Admission controllers are like security guards for the Kubernetes API server that check every request to create or change a resource before it is saved. They can modify the request, validate it against rules, or reject it entirely. This helps enforce security policies, prevent misconfigurations, and ensure only compliant resources are created in a cluster. Think of them as automated policy checkpoints that run your cluster's rules.
Must Know for Exams
The Certified Kubernetes Security Specialist (CKS) exam heavily tests your understanding of admission controllers. The official CKS curriculum includes topics like configuring and using admission controllers, especially PodSecurity standards, and implementing admission webhooks with tools like OPA or Kyverno. The exam expects you to know which admission controllers are enabled by default, how to enable or disable them, and how to write and deploy custom admission webhooks.
For example, you might be asked to create a validating admission webhook that rejects any pod that does not have a specific label. You will need to understand the difference between mutating and validating controllers, the order in which they run, and how to configure the API server flags. The exam also tests your ability to use PodSecurity standards (privileged, baseline, restricted) and how they map to admission controllers.
You may be given a scenario where a cluster has a security policy that must be enforced, and you must implement it using the appropriate admission controller or webhook. Additionally, the CKS exam includes questions about troubleshooting admission controllers. For instance, you might need to identify why a pod creation request is being rejected and trace the issue to a specific admission webhook that is misconfigured or returning an error.
Understanding how to view admission controller logs and how to test webhooks with curl commands is useful. The exam also covers the security implications of admission controllers themselves. For example, if an admission webhook is unavailable, it can block all API requests (by default), which can lead to a denial of service.
You must know how to configure the failure policy to handle such cases. The CNCF certified Kubernetes administrator (CKA) exam also touches on admission controllers, but in less depth. The CKA focuses more on cluster administration, while the CKS goes deep into security-specific controllers and webhooks.
For the CKS, you should be comfortable with YAML definitions for MutatingWebhookConfiguration and ValidatingWebhookConfiguration resources, and understand how to use Open Policy Agent (OPA) or Kyverno to implement custom policies. Mastering admission controllers is a high-yield area for the CKS because it directly tests your ability to enforce security policies in a real Kubernetes environment.
Simple Meaning
Imagine you want to enter a very secure office building. At the front door, there is a guard who checks your ID (that is authentication). Then, a second guard checks if you are allowed to be in that building based on your clearance level (that is authorization).
But even after you get inside, there are still more guards stationed at every door. These guards are admission controllers. They do not let you just walk into any room. They check what you are carrying, whether you have the right documents for that specific room, and whether your planned activity follows company policy.
If you try to bring a large bag into a lab that only allows small items, the guard stops you. If you want to enter a meeting room that requires a specific project code, the guard checks your paperwork. In Kubernetes, when you send a request to create a pod, a service, or any other object, the API server runs it through these admission controllers.
They can change the request (for example, add a default label or a security setting) if they are mutating controllers. Or they can simply check the request and say yes or no (validating controllers). If any controller says no, the whole request is rejected.
The request is only saved to the cluster's database (etcd) after all admission controllers have given their approval. This means admission controllers act as a powerful gatekeeper for everything that goes into your cluster, enforcing security, compliance, and operational best practices at the point of entry. Without them, a developer could accidentally deploy a container running as root, or a pod could request more memory than the cluster can provide, causing problems across the entire system.
Full Technical Definition
Admission controllers are a core component of the Kubernetes API server request lifecycle. When a request reaches the API server, it first passes through authentication (verifying the identity of the user or service account) and then authorization (checking if the authenticated entity has permission to perform the requested action). Only after these two steps does the request enter the admission control phase.
The admission control phase is divided into two stages: mutating admission controllers run first, followed by validating admission controllers. Mutating controllers can modify the request payload before it is persisted. For example, the NamespaceLifecycle admission controller ensures that the namespace is not terminating when a new object is created within it.
The DefaultStorageClass mutating admission controller automatically adds a default storage class to PersistentVolumeClaims that do not already specify one. The PodSecurity admission controller (which replaced PodSecurityPolicy in Kubernetes 1.23+) can mutate pods to add security context defaults.
After all mutating controllers have run and potentially altered the request, the validating admission controllers execute. These controllers do not modify the request; they only evaluate it against a set of rules. For example, the ResourceQuota admission controller checks that the new object does not violate the resource quotas defined in the namespace.
The PodNodeSelector admission controller enforces that pods only use node selectors permitted by the namespace's annotation. The LimitRanger admission controller validates that resource limits and requests are within acceptable ranges. Both mutating and validating admission controllers can be either built-in controllers that ship with Kubernetes or custom controllers implemented via admission webhooks.
Admission webhooks are HTTP callbacks that receive admission requests and return admission responses, allowing administrators to integrate external policy engines like Open Policy Agent (OPA) or custom scripts. The sequence is important: if a mutating webhook modifies a request, the modified version is then sent to the validating webhooks. This order ensures that validation happens against the final, potentially modified object, not the original request.
If any admission controller (mutating or validating) rejects the request, the entire request fails and an error is returned to the client. The object is never persisted in etcd. The list of enabled admission controllers is configured in the API server's --enable-admission-plugins flag.
Many controllers are enabled by default and are considered essential for cluster stability and security. In production clusters, administrators typically add custom admission webhooks to enforce organization-specific policies, such as requiring all images to come from a trusted registry or ensuring that all pods have resource limits defined.
Real-Life Example
Think of a university library that has a strict entry procedure. When you arrive, you first show your student ID card at the front desk to prove you are a student (authentication). Then, the librarian checks a list to see if you are allowed to enter the library at this hour and if your ID is not expired (authorization).
But that is not the end. Before you can actually walk into the reading room, you must pass through a set of checkpoints. The first checkpoint is a mutating admission controller. A librarian looks at your bag and says, 'I see you have a laptop.
I will put a special sticker on it so the security system knows it is yours. Also, I will stamp your hand with invisible ink that shows your entry time.' The librarian changes your entry profile by adding these details.
After that, you proceed to the next checkpoint, a validating admission controller. Another librarian checks your bag sticker and your hand stamp. They also look at a list of banned items.
If you are carrying a snack or a drink, the librarian says, 'Sorry, no food allowed in the reading room. You cannot enter.' That is a rejection. If everything is fine, the librarian lets you pass.
Only then are you recorded as having entered the library. The same process happens when you leave or when you want to access a special collections room. In Kubernetes, the admission controllers are those librarians.
The mutating ones add defaults, set labels, or attach security settings automatically. The validating ones check policies like resource quotas, security contexts, and namespace restrictions. They ensure that every resource in the cluster conforms to the rules before it is saved.
If a pod tries to run with root privileges but the cluster policy forbids it, the validating admission controller rejects it before it can cause any harm. This is a powerful safeguard that prevents mistakes and security breaches from ever becoming part of the cluster's state.
Why This Term Matters
Admission controllers matter because they are the last line of defense before any change is permanently recorded in a Kubernetes cluster. Without them, any authenticated and authorized user could create resources that violate security best practices, break resource limits, or bypass compliance requirements. For example, a developer might accidentally deploy a container that runs as root, which is a major security risk in a multi-tenant environment.
An admission controller like PodSecurity can prevent that by requiring a non-root user. Similarly, a team might forget to set resource requests and limits, which can lead to CPU starvation for other pods on the same node. The LimitRanger admission controller can automatically enforce minimum and maximum resource values.
In real IT work, admission controllers are used to enforce enterprise-wide policies across all clusters. They are essential for supply chain security because they can verify that container images come from an approved registry and have been scanned for vulnerabilities. They also support compliance with standards like PCI DSS, HIPAA, or SOC 2 by ensuring that every resource meets specific criteria.
For cloud-native security, admission controllers are a key component of a layered security approach. They complement network policies, RBAC, and runtime security tools. By catching policy violations at admission time, they prevent insecure configurations from ever reaching production.
This reduces the attack surface and simplifies incident response. Additionally, admission controllers help maintain cluster stability. They can enforce best practices like requiring that pods have readiness probes, resource limits, and anti-affinity rules.
They can also prevent the creation of objects that would exceed namespace quotas, which protects against resource exhaustion attacks. In summary, admission controllers are a critical tool for any Kubernetes administrator who needs to balance developer agility with security and operational discipline.
How It Appears in Exam Questions
In the CKS exam, questions about admission controllers come in several forms. Scenario-based questions are common: you are given a description of a security requirement (for example, all pods must run with a read-only root filesystem) and you must implement it using an admission controller. You may need to decide whether to use a built-in controller like PodSecurity or a custom webhook.
Another type of question is configuration: you might be asked to enable a specific admission controller by editing the API server manifest or by applying a YAML file for a webhook. For example, a question could ask you to create a ValidatingWebhookConfiguration that blocks any pod that does not have the label 'security-level: high'. You will need to write the YAML, including the webhook endpoint, the rules, and the failure policy.
Troubleshooting questions also appear. The exam might present a situation where a pod creation request is failing with an error like 'Internal error occurred: failed calling webhook'. You must diagnose the cause, which could be a misconfigured webhook endpoint, an expired TLS certificate, or a network issue.
You would then need to fix it, perhaps by updating the webhook configuration or checking the service. Another pattern is comparison questions where you must distinguish between mutating and validating controllers. For instance, you might be asked which type of controller would be used to automatically add a default storage class to a PVC.
The answer is a mutating admission controller because it modifies the request. The exam also includes questions about the admission control phase order. You could be asked: 'In which order do admission controllers run?'
and the correct answer is mutating first, then validating. There are also integration questions: how do admission controllers interact with RBAC? A learner might think that RBAC alone is enough for security, but admission controllers add another layer.
Questions may ask why you need both. Finally, there are multi-choice questions about default admission controllers. For example, 'Which of the following is NOT a default admission controller?'
You must know the list of default controllers for your Kubernetes version. The key is that admission controllers are not optional. They are always in play. Exam questions test whether you understand that fact and can apply it.
Study cncf-cks
Test your understanding with exam-style practice questions.
Example Scenario
A company runs a Kubernetes cluster for its development team. The security team has a policy that all containers must run as a non-root user and must not have privileged access to the host. A developer named Alex creates a pod YAML file that accidentally sets securityContext.
privileged to true and does not specify a runAsUser. Alex applies the YAML file using kubectl. The request reaches the API server. After authentication and authorization, the request enters the admission control phase.
The first set of mutating admission controllers run. The PodSecurity admission controller, which is enabled in 'restricted' mode, sees that the pod does not have a runAsUser set. It automatically mutates the request to add runAsUser: 1000, which is a non-root user.
It also adds other security defaults like allowing only the NET_BIND_SERVICE capability. After mutation, the validating admission controllers run. The PodSecurity validating controller now checks the final version of the pod.
It sees that the pod still has 'privileged: true' set, which violates the restricted policy. The controller rejects the request, and Alex receives an error message saying the pod was not allowed due to a PodSecurity violation. Alex then removes the privileged flag, re-applies the YAML, and this time the pod is successfully created with the non-root user and restricted security context.
In this scenario, the admission controller prevented a potentially dangerous pod from ever being created, even though the developer was authorized to create pods. The mutation also improved the pod's security automatically by adding a non-root user. This is a classic example of how admission controllers enforce security policies without requiring developers to be security experts.
Common Mistakes
Thinking that admission controllers run before authentication and authorization.
Admission controllers run after authentication and authorization are complete. The API server first verifies who is making the request and whether they have permission, then passes the request to admission controllers. If a user is not authenticated or authorized, the request is rejected before admission controllers ever see it.
Remember the order: authentication, then authorization, then admission control. Admission controllers are the last step before the object is persisted in etcd.
Believing that all admission controllers are validating (they only reject or accept).
There are two types of admission controllers: mutating and validating. Mutating controllers can modify the request (for example, by adding default values), while validating controllers only check the request. Both run in sequence, with mutating controllers first.
Always consider whether the task requires changing the object (use a mutating controller) or just checking it (use a validating controller). For adding defaults, use a mutating controller.
Assuming that disabling an admission controller is safe because other security measures exist.
Admission controllers provide a critical layer of defense. Disabling default controllers like NamespaceLifecycle or PodSecurity can lead to security gaps and operational issues. For example, disabling PodSecurity allows pods to run with privileged access, which can compromise the host node.
Only disable admission controllers if you fully understand the consequences and have alternative controls in place. In production, it is safer to keep default controllers enabled and add custom ones as needed.
Confusing admission controllers with network policies or RBAC.
Admission controllers operate at the API server level during resource creation, update, or deletion. Network policies control traffic between pods after they are running. RBAC controls who can perform actions in the cluster. They are separate layers. Admission controllers can enforce policies that RBAC cannot, such as checking container image sources.
Think of admission controllers as a pre-save checkpoint. RBAC is about permissions, network policies are about traffic flow, and admission controllers are about the content of the request itself.
Not handling admission webhook failures gracefully, assuming the webhook will always be available.
If a validating or mutating admission webhook is unreachable (for example, due to a network issue or misconfiguration), the default behavior is to fail closed, which means the API server rejects all requests that would be processed by that webhook. This can cause a cluster-wide outage.
Configure the failurePolicy field in the webhook configuration to 'Ignore' if the webhook is non-critical, so that failures are ignored. For critical security policies, keep the default 'Fail' but ensure the webhook is highly available and monitored.
Exam Trap — Don't Get Fooled
A question might ask you to set up a pod to run with a specific non-root user, and you think you must manually edit every pod YAML to set the runAsUser field. The trap is that you might forget about mutating admission controllers that can automatically add this value. Always consider whether a mutating admission controller can automate the task.
For adding default security contexts, use a PodSecurity admission controller configured with the 'baseline' or 'restricted' profile, or write a custom mutating webhook. This saves time and ensures consistency. In the exam, if you see a task that involves adding a default value to every new pod, think of admission controllers first.
Commonly Confused With
RBAC controls who can perform actions (like creating pods) based on roles and permissions. Admission controllers control what the action produces (like what security settings the pod has). RBAC says 'you are allowed to create pods.' Admission controllers say 'the pod you created must meet these rules.' They work together but are different layers.
Imagine a bank. RBAC is like a guard checking if you are a teller before letting you into the vault. Admission controllers are like a checklist that says every item taken from the vault must have an inventory tag. RBAC lets you enter; admission controllers check what you take out.
Network policies control network traffic between pods after they are running in the cluster. Admission controllers control whether a pod is allowed to be created at all. A network policy cannot stop a pod from being created with root privileges, but an admission controller can. They operate at different points in the lifecycle.
Think of a hotel. A network policy is like a rule that says guests cannot knock on doors on the fifth floor. An admission controller is like the front desk checking that every guest has a reservation before giving them a room key. The front desk stops bad guests from entering. The network policy stops them from bothering others once inside.
Pod Security Policies were an older Kubernetes feature that enforced security rules for pods. They were deprecated in Kubernetes 1.21 and removed in 1.25. Admission controllers, including the newer PodSecurity admission controller, replaced PSP. The new approach uses built-in admission controllers instead of a separate resource type.
PSP was like a single guard with a fixed rulebook. The new admission controllers are like a team of guards that can be easily updated and customized. If the old guard left, you had to replace the whole book. With admission controllers, you just add a new webhook or adjust a profile.
Service mesh sidecar injectors are often implemented as mutating admission webhooks. They automatically add a sidecar proxy container to every pod. While they use the same mechanism (admission webhooks), they are a specific application of admission controllers, not the controllers themselves. Admission controllers are the framework; sidecar injection is one use case.
Admission controllers are the postal sorting system. A sidecar injector is a specific stamp that says 'add a tracking label to every package.' The sorting system applies the stamp. The stamp is not the sorting system.
Step-by-Step Breakdown
Client sends a request
A user or an automated process uses kubectl or sends an API call to create, update, or delete a Kubernetes resource, such as a pod, service, or namespace. This request is sent to the Kubernetes API server.
Authentication
The API server verifies the identity of the requestor. This is done using certificates, tokens, or other authentication methods. If the identity cannot be verified, the request is rejected with an authentication error.
Authorization
After authentication, the API server checks if the authenticated user or service account has permission to perform the requested action. This uses RBAC or other authorization modules. If the user lacks permission, the request is denied.
Mutating admission controllers execute
After authorization, the request is passed to all enabled mutating admission controllers. These controllers can modify the request payload. For example, they can add default labels, set security context values, or inject sidecar containers. They run in a specific order, and changes made by one controller are visible to subsequent mutating controllers.
Validating admission controllers execute
After all mutating controllers have finished, the request (now possibly modified) is sent to all enabled validating admission controllers. These controllers check the request against policy rules. They cannot modify the request. If any validating controller rejects the request, the entire operation fails.
Object is persisted in etcd
If all mutating and validating admission controllers approve the request, the resource object is stored in the cluster's etcd database. The object is now a permanent part of the cluster state and can be scheduled or used.
Response is returned to the client
The API server sends a response back to the client. If the request was successful, the response includes the created or updated object. If the request was rejected by an admission controller, the response includes an error message explaining why.
Practical Mini-Lesson
In a real Kubernetes environment, admission controllers are a critical operational tool. As a Kubernetes administrator, you will encounter them in several ways. First, you must know which admission controllers are enabled by default in your cluster.
You can check this by looking at the API server pod's command-line flags or by querying the API server's configuration. The default set typically includes controllers like NamespaceLifecycle, LimitRanger, ServiceAccount, PodSecurity, NodeRestriction, and others. You should never disable these lightly because they provide essential safety nets.
However, you will often need to add custom policies. This is where admission webhooks come in. You can create a MutatingWebhookConfiguration or ValidatingWebhookConfiguration resource that points to a webhook endpoint, typically a service running inside the cluster.
For example, you might deploy Open Policy Agent (OPA) as an admission webhook. OPA can evaluate a wide range of policies written in Rego, a policy language. A typical policy might require that all pods have a specific label like 'team: frontend' or that container images come from an internal registry only.
To set this up, you need to write the policy, deploy OPA, create the webhook configuration, and ensure TLS certificates are configured for secure communication between the API server and the webhook. Another common tool is Kyverno, which is designed specifically for Kubernetes and uses YAML-based policies instead of Rego. Kyverno can enforce policies like 'all containers must have resource limits' or 'no containers can run as root.'
It can also generate resources based on templates. When implementing admission webhooks, you must be careful about the failurePolicy. Setting it to 'Fail' (default) will block all API requests if the webhook is unreachable.
Setting it to 'Ignore' allows requests to pass through even if the webhook fails, which is useful for non-critical policies. However, for security-critical policies, you want to fail closed. You also need to monitor webhook health and set up alerts for failures.
A common gotcha is that if you deploy a mutating webhook that modifies pods, you must ensure it does not cause infinite loops. For example, if your webhook adds a label and the label triggers another webhook that also adds the same label, you can get a cycle. The API server has safeguards against this, but it is best to test thoroughly.
In production, use a combination of built-in admission controllers and custom webhooks. The built-in controllers handle standard policies like resource quotas and namespace lifecycle, while custom webhooks handle organization-specific rules. This layered approach ensures security and compliance without sacrificing developer velocity.
Regularly audit your admission controller configurations and review webhook logs to catch misconfigurations early.
Memory Tip
Think AAA for the API server flow: Authentication, Authorization, then Admission. Admission controllers are the final checkpoint before the object is saved. For the exam, remember: mutating comes first (like adding defaults), validating comes second (like checking rules).
Covered in These Exams
Related Glossary Terms
Frequently Asked Questions
Do admission controllers run for every API request, including reads?
No. Admission controllers only run for requests that create, update, or delete resources. They do not run for read requests (like get, list, or watch). They are designed to enforce policies on changes to the cluster state.
Can I use multiple admission webhooks at the same time?
Yes, you can configure multiple mutating and validating webhooks. They run in the order determined by the webhook configurations' 'objectSelector' and 'reinvocationPolicy' settings. However, be careful about ordering conflicts, especially with mutating webhooks that might overwrite each other's changes.
What happens if an admission webhook fails?
It depends on the failurePolicy configured in the webhook configuration. If set to 'Fail', the API request is rejected. If set to 'Ignore', the request continues as if the webhook did not run. The default is 'Fail' for security reasons.
How do I test an admission webhook during development?
You can use tools like kubectl with dry-run to simulate requests, or you can send direct HTTP requests to the API server with a test payload. You can also deploy the webhook in a non-production cluster and create resources that should trigger it. Logs from the webhook service will show the admission decisions.
Are admission controllers the same as Kubernetes Webhooks?
No. Admission controllers are a general concept, and webhooks are a specific way to implement custom admission controllers. Built-in admission controllers (like NamespaceLifecycle) are compiled into the API server. Webhooks are external services called via HTTP to make admission decisions.
What is the difference between a mutating admission webhook and a validating admission webhook?
A mutating webhook can modify the request object (for example, by adding a label or changing a security setting). A validating webhook can only accept or reject the request; it cannot change it. Mutating webhooks run before validating webhooks.
Summary
Admission controllers are a vital security and policy enforcement mechanism within Kubernetes. They act as gatekeepers that inspect and potentially modify every request to create, update, or delete a resource before it is stored in the cluster's database. By running after authentication and authorization, they provide a third layer of defense that can catch misconfigurations, enforce security standards, and ensure compliance with organizational policies.
They are divided into two types: mutating controllers that can automatically add defaults or fix security settings, and validating controllers that strictly check policies. For the CKS exam, you must understand how to configure built-in admission controllers, how to deploy and manage admission webhooks, and how to troubleshoot common issues like webhook failures. In real-world practice, admission controllers are essential for supply chain security, multi-tenant isolation, and operational stability.
They are not optional; every Kubernetes cluster runs them by default. The key takeaway for learners is that admission controllers are your automated enforcer. They ensure that every resource in the cluster meets the rules you define, reducing human error and improving security posture.
Mastery of this concept is critical for any Kubernetes security professional, and it is a heavily tested area in the CKS certification.