2025 Updates Solution Admission Controllers

In this article, we review the lab solutions related to admission controllers. We will analyze several questions, demonstrate validation techniques using command-line operations, and show manifest file edits to enforce specific configurations.

Question 1: Function of Admission Controllers

The first question asks which task admission controllers do not perform. The correct answer is that they do not handle user authentication. Admission controllers come into effect after authentication, enforcing policies by validating or mutating resources.

Question 2: Enabling the Default Admission Controllers

The next question examines which admission controller is not enabled by default. To determine this:

1. List the control plane pods in the kube-system namespace:

   root@controlplane ~ ➜ kubectl get pods -n kube-system
   NAME                                     READY   STATUS    RESTARTS   AGE
   coreDNS-74ff55c5b-88v8r                 1/1     Running   0          38m
   coreDNS-74ff55c5b-tng7p                 1/1     Running   0          38m
   etcd-controlplane                        1/1     Running   0          38m
   kube-apiserver-controlplane              1/1     Running   0          38m
   kube-controller-manager-controlplane     1/1     Running   0          38m
   kube-flannel-ds-wzlpx                   1/1     Running   0          38m
   kube-proxy-hccb9                         1/1     Running   0          38m
   kube-scheduler-controlplane              1/1     Running   0          38m
   

2. Inspect the kube-apiserver pod (e.g., kube-apiserver-controlplane). Execute a shell inside the pod and search for the enabled admission plugins:

   kubectl exec -it <kube-apiserver-pod-name> -n kube-system -- kube-apiserver -h | grep "enable admission plugins"
   

   The output confirms that while plugins such as mutating and validating admission webhooks are present, the "namespace auto-provision" admission controller is absent. This controller is therefore not enabled by default.

Question 3: Admission Controller Enabled by Default (But Normally Disabled)

This question asks which admission controller is active in the cluster that is usually disabled by default. To answer:

1. Open the kube-apiserver configuration file at /etc/kubernetes/manifests/kube-apiserver.yaml.

2. Run the following command to locate the admission plugin configuration:

   kubectl exec -it <kube-apiserver-pod-name> -n kube-system -- grep enable-admission-plugins /etc/kubernetes/manifests/kube-apiserver.yaml
   

   You should see an output similar to:

   apiVersion: v1
   kind: Pod
   metadata:
     annotations:
       kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 10.49.219.9:6443
     labels:
       component: kube-apiserver
       tier: control-plane
     name: kube-apiserver
     namespace: kube-system
   spec:
     containers:
     - command:
       - kube-apiserver
       - --advertise-address=10.49.219.9
       - --allow-privileged=true
       - --authorization-mode=Node,RBAC
       - --client-ca-file=/etc/kubernetes/pki/ca.crt
       - --enable-admission-plugins=NodeRestriction
       - --enable-bootstrap-token-auth=true
       - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
       - --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
       - --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key
       - --etcd-servers=https://127.0.0.1:2379
       - --insecure-port=0
       - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt
       - --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key
       - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
       - --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt
   

   From this configuration, it is clear that the "NodeRestriction" plugin is enabled, even though it is not typically activated by default in standard configurations.

Question 4: Creating an NGINX Pod without Pre-Creating the Namespace

In this task, we create an NGINX pod in a non-existent namespace called "blue." This operation will help us understand how Kubernetes responds when the specified namespace is missing.

Execute the following command:

kubectl run nginx --image nginx --namespace blue

Since the "blue" namespace does not exist, the command returns an error:

Error from server (NotFound): namespaces "blue" not found

This error occurs because the "namespace exists" admission controller (enabled by default) rejects requests for non-existent namespaces. To enable automatic creation of missing namespaces, the Namespace Auto-Provision admission controller must be activated.

Enabling the Namespace Auto-Provision Admission Controller

To enable automatic namespace creation, update the API server manifest at /etc/kubernetes/manifests/kube-apiserver.yaml as follows:

1. Locate the line with --enable-admission-plugins.

2. Add the NamespaceAutoProvision plugin, making the line appear as shown below:

   apiVersion: v1
   kind: Pod
   metadata:
     annotations:
       kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 10.49.219.9:6443
     creationTimestamp: null
     labels:
       component: kube-apiserver
       tier: control-plane
     name: kube-apiserver
     namespace: kube-system
   spec:
     containers:
     - command:
       - kube-apiserver
       - --advertise-address=10.49.219.9
       - --allow-privileged=true
       - --authorization-mode=Node,RBAC
       - --client-ca-file=/etc/kubernetes/pki/ca.crt
       - --enable-admission-plugins=NodeRestriction,NamespaceAutoProvision
       - --enable-bootstrap-token-auth=true
       - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
       - --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
       - --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key
       - --etcd-servers=https://127.0.0.1:2379
       - --insecure-port=0
       - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt
       - --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key
       - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
       - --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt
   

Once the API server is up, create the NGINX pod again:

kubectl run nginx --image nginx -n blue

To verify that the blue namespace was auto-created, list all namespaces:

kubectl get ns

Expected output:

NAME                STATUS   AGE
blue                Active   7s
default             Active   50m
kube-node-lease     Active   50m
kube-public         Active   50m
kube-system         Active   50m

This confirms that the Namespace Auto-Provision admission controller is functioning correctly.

Question 5: Disabling the Default Storage Class Admission Controller

The final task involves disabling the default storage class admission controller. This is accomplished by modifying the API server manifest.

1. Open the file /etc/kubernetes/manifests/kube-apiserver.yaml.

2. Directly after the --enable-admission-plugins flag, add the disable flag for the DefaultStorageClass plugin (--disable-admission-plugins=DefaultStorageClass) as shown below:

   apiVersion: v1
   kind: Pod
   metadata:
     annotations:
       kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 10.49.219.9:6443
     creationTimestamp: null
     labels:
       component: kube-apiserver
       tier: control-plane
     name: kube-apiserver
     namespace: kube-system
   spec:
     containers:
     - command:
       - kube-apiserver
       - --advertise-address=10.49.219.9
       - --allow-privileged=true
       - --authorization-mode=Node,RBAC
       - --client-ca-file=/etc/kubernetes/pki/ca.crt
       - --enable-admission-plugins=NodeRestriction,NamespaceAutoProvision
       - --disable-admission-plugins=DefaultStorageClass
       - --enable-bootstrap-token-auth=true
       - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
       - --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
       - --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key
       - --etcd-servers=https://127.0.0.1:2379
       - --insecure-port=0
       - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt
       - --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key
       - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
       - --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt
   

After the API server restarts, test the configuration with:

kubectl run nginx --image nginx -n blue
kubectl get ns

A successful pod creation and the updated namespace list confirm that the default storage class admission controller is disabled.

Example command-line output:

root@controlplane ~ ➜ kubectl run nginx --image nginx -n blue
pod/nginx created
root@controlplane ~ ➜ kubectl get ns
NAME              STATUS   AGE
blue              Active   7s
default           Active   50m
kube-node-lease   Active   50m
kube-public       Active   50m
kube-system       Active   50m

Summary

To summarize, in this lab we:

1. Identified the function of admission controllers and clarified that they do not manage user authentication.
2. Determined which admission controllers are enabled by default.
3. Enabled the Namespace Auto-Provision admission controller to automatically create namespaces.
4. Disabled the default storage class admission controller through modifications to the API server manifest.

This concludes the Admission Controllers Lab for the 2025 updates. For additional Kubernetes configuration guides, please refer to the Kubernetes Documentation.