Home / Knowledge hub / Pod security standards
Knowledge hub
Pod security standards
Built-in Kubernetes levels that restrict risky settings in pods.
What it means
The Pod Security Standards are a set of three policy levels defined by Kubernetes. Privileged is unrestricted. Baseline blocks the known routes to privilege escalation while staying easy to adopt. Restricted follows current hardening practice and is the strictest.
They describe what a pod is allowed to ask for: host access, extra capabilities, running as root and similar. The standards are the rules. A separate built-in mechanism, Pod Security Admission, applies them.
Why it matters
Without a rule, any team that can create pods can ask for powers that put the host at risk. One privileged container or host mount lowers the safety of every workload on that node.
A standard gives you a plain answer to what is allowed here. It is far easier to enforce one named level per namespace than to review every manifest by eye, and it is easier to explain to an auditor.
How it shows up
Pod Security Admission works per namespace. You label a namespace with the level and the mode: enforce to reject pods, audit to log violations, or warn to tell the person applying them. It replaced PodSecurityPolicy, which was removed in Kubernetes 1.25.
A sensible path is to start in warn and audit mode, fix what is flagged, then enforce Baseline broadly and Restricted where you can. Use an admission controller or policy tool if you need rules beyond the three levels.
Questions people ask
Pod security standards, answered
What are the three levels?
Privileged, Baseline and Restricted. They run from no restrictions, through a minimum sensible set, to heavily restricted.
Is Pod Security Admission the same as the standards?
No. The standards are the policies. Pod Security Admission is the built-in controller that enforces them on namespaces.
What replaced PodSecurityPolicy?
Pod Security Admission, which is simpler. PodSecurityPolicy was removed in Kubernetes 1.25.
Will Restricted break our apps?
Possibly, because it requires non-root users and dropped capabilities. Use audit and warn modes first to find what needs changing.
Do the standards cover network rules?
No. They cover pod settings only. Traffic between pods is controlled by network policy.
Sources
Where this comes from
Related
Terms that sit next to this one
Privileged container
A container given near-host powers, so a flaw inside it is a flaw in the host.
Admission controller
A cluster gate that can reject workloads breaking your security rules.
Cluster hardening
Tightening a Kubernetes setup against published good-practice benchmarks.
Kubernetes network policy
Rules that say which pods may talk to which other pods.
Container escape
Breaking out of a container to reach the machine that hosts it.
Which level is each namespace on?
Pod rules protect the host. We test the application on top, and report what we exploited with the evidence. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.