Hands-on Lab·Certified Kubernetes Security Specialist
Pod Security Admission: enforce, audit and warn
Every namespace you create admits a privileged container and says nothing about it. This guide turns that off in the order a real rollout needs - find out what breaks, record it, then refuse it - and shows the one thing labelling a namespace will never do.
Microservice Vulnerabilities Guide 18 of 40 Intermediate
- Kubernetesapiserver v1.36.4, kubelet v1.36.3
- Runtimecontainerd 2.2.6
- CNICilium 1.18.1
- Built withkubeadm v1.36.3
- TimeAbout 17 min
Pod Security Admission is built into the apiserver and is configured entirely with namespace labels. There is no controller to install and nothing to keep running.
- Host kernel7.0.0-29
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA6001 | 192.168.0.46 | Ubuntu 26.04 LTS | Control Plane Node (tainted NoSchedule) | 2 Core | 4 GB | 50 GB |
| CKA6001-NODE01 | 192.168.0.47 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA6001-NODE02 | 192.168.0.48 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when a namespace has to stop admitting privileged containers. This matters because every namespace you create admits one silently - and the rollout goes warn, then audit, then enforce, in that order for a reason.
- creating a namespace with no level set, and putting the worst thing you can into it
- adding the warn and audit labels, which block nothing at all
- adding enforce, and reading the refusal it returns
- swapping restricted for baseline, and seeing what that level does not cover
Before you start
- guide 4 - the other namespace-level control.
-
A namespace with no level set
-
Warn and audit before you enforce
-
Enforce, and read the refusal
-
The level below, and what it does not cover