CertGrid CertGrid
Hands-on Lab·Kubernetes and Cloud Native Security Associate

Pod Security Standards in Detail

privileged, baseline and restricted are easy to recite and hard to place. This guide builds the matrix: an ordinary Pod and a privileged one, submitted to all three levels, plus the host-namespace case that shows what baseline is for.

Security Fundamentals Guide 22 of 42 Intermediate

Pod Security Admission is built into the apiserver, so none of this needs anything installed. The warning text names the version it evaluated against - restricted:latest here - which is why pinning enforce-version matters.

The cka5001 cluster: one control plane and 3 schedulable workers, on Cilium.
Server NameIP AddressOSRolesCPURAMHDD
CKA5001192.168.0.41Ubuntu 26.04 LTSControl Plane Node (tainted NoSchedule)2 Core4 GB50 GB
CKA5001-NODE01192.168.0.42Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB
CKA5001-NODE02192.168.0.43Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB
CKA5001-NODE03192.168.0.44Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB

This guide includes

Use this when privileged, baseline and restricted have to be placed rather than recited. This matters because the difference only becomes concrete once the same Pod is submitted to all three levels and two of them refuse it.

Before you start

  1. Three namespaces, one per level

  2. A privileged Pod: only one level takes it

  3. An ordinary Pod: the line between baseline and restricted

  4. Host namespaces, and what they actually expose

  5. warn mode, which is how a rollout actually happens

Official sources

← All KCSA guides