Kubernetes defines three Pod Security Standards. Privileged has no restrictions, Baseline blocks known privilege escalations while staying easy to adopt, and Restricted follows current hardening practice by also requiring non-root users, dropped capabilities and a seccomp profile. Most application namespaces should aim for Restricted.
The three levels in plain terms
Privileged is the open door. The Kubernetes documentation says pods at this level can bypass container isolation, for example by using the node's host network. It is meant for system and infrastructure workloads that genuinely need node access.
Baseline is the minimum you should accept for ordinary workloads. It is designed to be easy to adopt, so many existing images pass without changes.
Restricted is stricter and may require you to rebuild images or adjust manifests.
What Baseline blocks
According to the standards page, Baseline requires that:
- hostNetwork, hostPID and hostIPC are unset or false
- privileged containers are not allowed
- added Linux capabilities stay within a short list that includes CHOWN, KILL, NET_BIND_SERVICE, SETUID and SETGID
- hostPath volumes are not used
- the seccomp profile is not set to Unconfined
- procMount stays at its default
The theme is simple: a pod should not share the node's namespaces, run privileged, or mount the node's filesystem.
What Restricted adds
Restricted includes everything in Baseline and tightens it. The documentation describes these additional requirements:
- seccomp profile set to RuntimeDefault or Localhost
- runAsNonRoot set to true
- allowPrivilegeEscalation set to false
- all capabilities dropped, with only NET_BIND_SERVICE allowed to be added back
- volume types limited to a short allowlist such as configMap, secret, emptyDir, projected and persistentVolumeClaim
Because the page is long, confirm the exact list for your Kubernetes version before you write policy around it.
Which one to choose
Use Restricted for new services and for namespaces you control end to end. Use Baseline as a landing spot for older workloads that cannot yet run as non-root, with a dated plan to move them. Keep Privileged for a small, named set of system namespaces, and keep application teams out of them.
A practical path is to turn on warn and audit at Restricted first, read the output, fix the manifests, and only then enforce. See Pod Security admission: enforce, audit and warn rollout for the steps.
Safeguard policies and gates can check manifests in the pull request, so a violation shows up before the cluster rejects the pod. That is a complement to admission control, not a replacement for it.
Quick check
Is Baseline enough for production?
For many legacy workloads it is an acceptable starting point, but it does not require non-root users or dropped capabilities. Treat Restricted as the target.
Do the standards replace RBAC or network policies?
No. They constrain what a pod spec may ask for. Access to the API and traffic between pods are handled by other controls.
Sources
Last reviewed: 19 October 2026.
