Hands-on Lab·Kubernetes and Cloud Native Security Associate

Pod Security Admission Levels

Pod Security Admission is the control a KCSA candidate is most likely to be asked about and least likely to have seen refuse anything. This guide labels a namespace restricted, submits an ordinary Pod, and reads the rejection.

Cloud Native Security Guide 6 of 42 Beginner

Kubernetesapiserver v1.36.4, kubelet v1.36.3
Runtimecontainerd 2.2.6
CNICilium 1.18.1
Built withkubeadm v1.36.3
TimeAbout 14 min

PSA is built into the apiserver and needs nothing installed - which is why it works on this cluster where no admission webhook exists at all. The three levels (privileged, baseline, restricted) and three modes (enforce, audit, warn) are stable API.

Host kernel7.0.0-29

The cka5001 cluster: one control plane and 3 schedulable workers, on Cilium.
Server Name	IP Address	OS	Roles	CPU	RAM	HDD
CKA5001	192.168.0.41	Ubuntu 26.04 LTS	Control Plane Node (tainted NoSchedule)	2 Core	4 GB	50 GB
CKA5001-NODE01	192.168.0.42	Ubuntu 26.04 LTS	Worker Node	2 Core	4 GB	50 GB
CKA5001-NODE02	192.168.0.43	Ubuntu 26.04 LTS	Worker Node	2 Core	4 GB	50 GB
CKA5001-NODE03	192.168.0.44	Ubuntu 26.04 LTS	Worker Node	2 Core	4 GB	50 GB

This guide includes

Use this because Pod Security Admission is the control KCSA is most likely to ask you about. This matters because it is built into the API server and needs nothing installed - one label on a namespace is the entire configuration.

creating two namespaces where the only difference between them is a label
applying the identical Pod to both and getting opposite results
reading the violation list that the rejection hands back

Before you start

guide 3 - which showed 5 of 5 namespaces with no PSA label at all.

Two namespaces, one of them labelled
The label is the entire configuration. There is nothing to install.
bash Example session
```
$kubectl create ns kcsa-open >/dev/null && kubectl create ns kcsa-strict >/dev/null && kubectl label ns kcsa-strict pod-security.kubernetes.io/enforce=restricted pod-security.kubernetes.io/warn=restricted >/dev/null && kubectl get ns kcsa-open kcsa-strict -o custom-columns='NAME:.metadata.name,ENFORCE:.metadata.labels.pod-security\.kubernetes\.io/enforce'NAME          ENFORCEkcsa-open     <none>kcsa-strict   restricted
```
Note
PSA is opt-in per namespace and does nothing until you label one. That is why the default cluster had zero enforcement across all five namespaces - not a misconfiguration, just the default.

Three levels, in increasing strictness: privileged allows everything and is the default when no label is present; baseline blocks known privilege escalations - host namespaces, privileged containers, most hostPath; restricted additionally requires non-root, dropped capabilities, a seccomp profile and no privilege escalation.

Three modes, and they are independent. enforce refuses the Pod. audit records a violation in the audit log and allows it. warn returns a warning to the client and allows it. Labelling warn and audit first, then enforce later, is how you adopt this without breaking a running namespace - and it is the answer to "how would you roll this out".

The label can pin a version: pod-security.kubernetes.io/enforce-version: v1.31. Without it the level means whatever the current apiserver thinks it means, which can change on upgrade.

PSA does not apply to the control plane's own Pods or to anything created before the label. It is an admission controller: it judges what is submitted, not what already exists.

Expected resultkcsa-open with ENFORCE <none>, kcsa-strict with ENFORCE restricted.

Success conditionYou have a controlled namespace and an uncontrolled one to compare.
The same Pod, twice
Identical spec. One namespace takes it, the other does not.
bash Example session
```
$kubectl -n kcsa-open run plain --image=docker.io/library/busybox:1.37 --restart=Never --command -- sh -c 'sleep 600' 2>&1 | tail -1; kubectl -n kcsa-open wait --for=condition=Ready pod/plain --timeout=120spod/plain createdpod/plain condition met$kubectl -n kcsa-strict run plain --image=docker.io/library/busybox:1.37 --restart=Never --command -- sh -c 'sleep 600' 2>&1 | head -4; echo "--- the SAME Pod spec, refused. Pod Security Admission names every rule it broke"Error from server (Forbidden): pods "plain" is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "plain" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "plain" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "plain" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "plain" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")--- the SAME Pod spec, refused. Pod Security Admission names every rule it broke
```
Note
This is the whole point of the page. Most candidates can define the three levels and have never watched one reject a Pod. The rejection is an admission error at submit time - the Pod is never created, never scheduled, and never appears in kubectl get pods.

The message lists every rule broken, not just the first: an unrestricted busybox Pod violates allowPrivilegeEscalation, capabilities, runAsNonRoot and seccompProfile all at once. Read the whole message - it is a checklist of what to fix, and the next page fixes exactly those.

Forbidden here is admission, not RBAC. The same word appears for both, which is a genuine source of confusion. An RBAC Forbidden says the user cannot perform the verb; a PSA Forbidden says the object is not acceptable. The body of the message is what distinguishes them.

Deployments fail differently, and worse. A Deployment whose Pod template violates the policy is accepted - the Deployment is a valid object - and then its ReplicaSet cannot create Pods. You get a healthy-looking Deployment with zero replicas and the real error buried in kubectl describe replicaset. That asymmetry is worth remembering.

Expected resultpod/plain created and condition met in kcsa-open. In kcsa-strict: Error from server (Forbidden): pods "plain" is forbidden: violates PodSecurity "restricted".

Success conditionYou have seen the control refuse something.

Troubleshooting

PSA is not restricting anything.

Why: No namespace carries a pod-security.kubernetes.io/enforce label.

Fix:It is opt-in per namespace. Label it, or nothing happens.
A Deployment reports no error but no Pods appear.

Why: The Deployment was accepted; its ReplicaSet cannot create Pods.

Fix:kubectl describe replicaset - the PSA rejection is on the ReplicaSet's events.
Existing Pods keep running after a namespace is labelled.

Why: Admission judges submissions, not existing objects.

Fix:Expected. Recreate them, or use warn/audit first to find what would break.
A level's meaning changed after a cluster upgrade.

Why: No enforce-version label, so the level tracks the apiserver.

Fix:Pin it: pod-security.kubernetes.io/enforce-version: v1.31.
Forbidden and it is not clear whether RBAC or PSA.

Why: Both use the word.

Fix:Read the body. violates PodSecurity is admission; cannot <verb> is RBAC.

Official sources

← All KCSA guides

Pod Security Admission Levels

This guide includes

Before you start

Two namespaces, one of them labelled

The same Pod, twice

Troubleshooting

Official sources