2025 Updates Admission Controllers

In this lesson we cover Kubernetes admission controllers: what they are, where they run in the API request lifecycle, and how to list, enable, or disable them on your API server.

A presentation slide titled "Admission Controllers" against a white and dark-blue curved background. On the right is a gear/settings icon with three horizontal slider controls.

What happens when you run kubectl?

kubectl sends an HTTPS request to the Kubernetes API server.
The API server authenticates the request (for example, using client certificates from your kubeconfig).
The API server authorizes the requested action (for example, via RBAC).
Admission controllers then validate or mutate the request.
If the request is allowed, the object is persisted to etcd.

Example kubeconfig showing client certificate and API server endpoint:

# ~/.kube/config
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSU0rVWFERVk...
    server: https://10.10.1015:6443

Authentication vs Authorization

Authentication verifies who sent the request.
Authorization checks whether that identity is permitted to perform the requested action.
Role-Based Access Control (RBAC) is the standard Kubernetes mechanism for authorization.

Example RBAC Role allowing a developer to manage Pods:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["list", "get", "create", "update", "delete"]

Example RBAC Role restricted to creating only specific pod names:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["create"]
  resourceNames: ["blue", "orange"]

Why admission controllers? RBAC controls which API operations a user can call, but it does not inspect or change the object content. Admission controllers run after authentication and authorization, but before the object is stored in etcd. They can:

Validate requests (accept or reject).
Mutate requests (modify the object before persistence).
Take other side effects (for example, auto-provision a Namespace).

Common use-cases:

Block images from Docker Hub, allow only an internal registry.
Reject use of the latest image tag.
Deny containers that run as root.
Enforce required labels or metadata.
Inject sidecar containers or default environment variables.

Built-in admission controllers (examples)

Controller	Purpose
AlwaysPullImages	Forces imagePullPolicy to `Always` so images are pulled on every Pod start.
DefaultStorageClass	Sets `storageClassName` on PVCs that don’t specify one, using the default StorageClass.
EventRateLimitAdmissionController	Rate-limits events to protect the API server.
NamespaceExists	Rejects requests targeting namespaces that do not exist.
NamespaceAutoProvision	(Not enabled by default) Creates a namespace automatically if it does not exist.

When admission controllers run Order: Authentication → Authorization (RBAC) → Admission controllers → Persist to etcd. Because they execute before persistence, admission controllers are the right place to enforce cluster-wide policy, validate API objects, or mutate requests. Example — NamespaceExists vs NamespaceAutoProvision

If a namespace does not exist and NamespaceExists is enabled, creating a Pod in that namespace will be rejected:

$ kubectl run nginx --image nginx --namespace blue
Error from server (NotFound): namespaces "blue" not found

If NamespaceAutoProvision is enabled, the API server will create the namespace automatically and allow the Pod creation to proceed:

$ kubectl run nginx --image nginx --namespace blue
pod/nginx created!

$ kubectl get namespaces
NAME           STATUS    AGE
blue           Active    3m
default        Active    23m
kube-public    Active    24m
kube-system    Active    24m

Listing and changing enabled admission plugin flags To see which admission controllers are enabled by the API server binary:

kube-apiserver -h | grep enable-admission-plugins

On many kubeadm clusters, the API server runs as a static Pod (manifest in /etc/kubernetes/manifests) or as a systemd service. Edit the appropriate manifest or unit and update these flags:

To enable controllers: --enable-admission-plugins=ControllerA,ControllerB,...
To disable controllers: --disable-admission-plugins=ControllerX,ControllerY,...

Examples

systemd unit ExecStart (if API server runs as a systemd service):

ExecStart=/usr/local/bin/kube-apiserver \
  --advertise-address=${INTERNAL_IP} \
  --allow-privileged=true \
  --apiserver-count=3 \
  --authorization-mode=Node,RBAC \
  --bind-address=0.0.0.0 \
  --enable-swagger-ui=true \
  --etcd-servers=https://127.0.0.1:2379 \
  --event-ttl=1h \
  --runtime-config=api/all \
  --service-cluster-ip-range=10.32.0.0/24 \
  --service-node-port-range=30000-32767 \
  --v=2 \
  --enable-admission-plugins=NodeRestriction,NamespaceAutoProvision

kube-apiserver static Pod manifest (common with kubeadm):

apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - name: kube-apiserver
    image: k8s.gcr.io/kube-apiserver-amd64:v1.11.3
    command:
      - kube-apiserver
      - --authorization-mode=Node,RBAC
      - --advertise-address=172.17.0.107
      - --allow-privileged=true
      - --enable-bootstrap-token-auth=true
      - --enable-admission-plugins=NodeRestriction,NamespaceAutoProvision

After editing the unit file or the static Pod manifest, the API server process will restart and pick up the new flags (kubelet restarts static Pods when their manifests change).

The NamespaceExists and NamespaceAutoProvision controllers have been superseded by the NamespaceLifecycle admission controller. NamespaceLifecycle enforces that requests to non-existent namespaces are rejected and prevents deletion of core namespaces (for example, default, kube-system, kube-public).

Best practices and next steps

Use validating admission controllers or validating webhooks to enforce custom policies (for example, image registries or security contexts).
Use mutating admission controllers or mutating webhooks to inject defaults or sidecars.
Prefer central, cluster-wide policies (e.g., PodSecurityAdmission, OPA/Gatekeeper) over ad-hoc per-cluster scripts.
Test changes to the API server flags in a non-production environment first.

Links and references

Practice working with admission controllers and the --enable-admission-plugins / --disable-admission-plugins flags on a test cluster to understand how they affect API requests.

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

2025 Updates Admission Controllers

Watch Video

Practice Lab