In the context of Kubernetes Cluster Architecture, Admission Controllers act as vital gatekeepers within the API Server. They intercept requests to the Kubernetes API after the request has been authenticated and authorized, but before the object is persisted to the etcd data store.
There are two …In the context of Kubernetes Cluster Architecture, Admission Controllers act as vital gatekeepers within the API Server. They intercept requests to the Kubernetes API after the request has been authenticated and authorized, but before the object is persisted to the etcd data store.
There are two distinct phases of admission control:
1. **Mutating Phase**: These controllers run first and can modify the object sent in the request. For example, the 'ServiceAccount' controller injects default tokens into pods, or the 'AlwaysPullImages' controller forces the image pull policy to Always.
2. **Validating Phase**: These run after mutation and validate the object against specific schemas or constraints. If a validating controller rejects a request, the entire operation fails. Examples include 'NodeRestriction', which limits what kubelets can modify, and 'ResourceQuota', which ensures namespace limits aren't exceeded.
For the CKA exam, you must understand how to manage these via the kube-apiserver component. Admission controllers are compiled into the binary, and you enable or disable them using the `--enable-admission-plugins` and `--disable-admission-plugins` flags in the `kube-apiserver.yaml` manifest.
Furthermore, Kubernetes supports Dynamic Admission Control via Webhooks. This allows you to configure external HTTP callbacks (`MutatingWebhookConfiguration` and `ValidatingWebhookConfiguration`) to process requests. This mechanism is the foundation for advanced policy enforcement tools like OPA Gatekeeper or Kyverno, allowing administrators to enforce custom security standards without modifying the API server code directly.
Mastering Admission Controllers for CKA
Introduction Admission Controllers are a critical component in the Kubernetes control plane acting as the final gatekeepers. They are pieces of code located inside the kube-apiserver that intercept requests to the Kubernetes API server after the request is authenticated and authorized, but before the object is persisted to the etcd database.
Why are they Important? While Authentication answers "Who are you?" and Authorization answers "What can you do?", Admission Controllers answer "Is what you are trying to do valid, safe, and compliant?". They are crucial for: 1. Security: Preventing privileged containers or restricting images to trusted registries. 2. Governance: Enforcing labels, annotations, or unique naming conventions. 3. Automation: Automatically injecting sidecar containers (like service meshes) or setting default resource limits.
How it Works The admission control process operates in two distinct phases: Phase 1: Mutating Admission Controllers These execute first. They can modify (mutate) the object in the request. For example, the ServiceAccount controller modifies a Pod specification to add the default ServiceAccount if one is not specified. Phase 2: Validating Admission Controllers These execute after mutation. They validate the final object structure. They cannot change the object; they can only accept or reject the request. For example, LimitRanger checks if a Pod's resource request exceeds the namespace limits.
If any admission controller in either phase rejects the request, the entire request is rejected immediately, and an error is returned to the user.
Exam Tips: Answering Questions on Admission Controllers In the CKA exam, you will likely interact with the API Server static pod manifest. Here is how to handle these questions:
1. Enabling and Disabling Plugins You configure plugins via flags in the /etc/kubernetes/manifests/kube-apiserver.yaml file. To Enable: usage of --enable-admission-plugins=NamespaceLifecycle,LimitRanger,... To Disable: usage of --disable-admission-plugins=DefaultStorageClass,... Tip: Do not remove default plugins unless explicitly asked. Just append the new ones to the list using a comma.
2. The 'NodeRestriction' Plugin You may encounter a scenario requiring you to secure the kubelet. Ensure the NodeRestriction plugin is enabled. This prevents kubelets from modifying labels prefixed with `node-restriction.kubernetes.io/` and restricts them to modifying only their own Node object.
3. ImagePolicyWebhook Configuration This is a complex but common topic. It allows external backends to validate container images. Step A: Identify the configuration files (AdmissionConfiguration and kubeconfig) provided in the scenario. Step B: Mount these files into the API Server pod. You must edit the `volumeMounts` and `volumes` sections of the kube-apiserver.yaml so the container can read the files from the host. Step C: Add the flag --admission-control-config-file=/path/to/admission-config.yaml. Step D: Add ImagePolicyWebhook to the --enable-admission-plugins list.
4. Troubleshooting Strategy After editing the static pod manifest, the kube-apiserver will restart automatically. If it does not come back up (check with `crictl ps` or `kubectl get pods -n kube-system`), you likely made a YAML syntax error or pointed to a non-existent file path. Check the logs immediately using `crictl logs [container-id]` on the control plane node.