Cybersecurity glossary
What is Pod Security?
Learn what Kubernetes Pod Security is, how Privileged, Baseline, and Restricted profiles work, and how admission stops hostPath, root, and capability-heavy pods.
Definition
Pod Security is Kubernetes’ built-in admission policy that labels namespaces with Privileged, Baseline, or Restricted profiles so pods cannot request dangerous isolation breaks—such as privileged mode, host namespaces, or extra capabilities—unless the namespace explicitly allows them.
Why Pod Security matters
RBAC answers whether you may create a Pod. It does not answer whether that Pod may share the host PID namespace or mount /var/run/docker.sock. Without a spec policy, every developer with create pods can request a breakout.
Pod Security (the standards plus the admission plugin) is Kubernetes’ built-in answer: label the namespace, reject dangerous fields, and keep privileged as an exception with an owner—not as the default.
How Pod Security Admission evaluates a spec
The namespace is labeled
pod-security.kubernetes.io/enforce (and optional warn/audit) name a profile and version.
A Pod (or controller template) is submitted
Deployments, Jobs, and DaemonSets are checked via the Pod template they would create.
Fields are compared to the profile
privileged, hostPath, capabilities, runAsNonRoot, seccomp, and volume types are typical checks.
warn / audit / enforce fire
warn annotates the API response, audit writes logs, enforce rejects the object.
Exemptions are explicit
kube-system and certain runtime pods may be exempted. Each exemption is a documented exception.
The three profiles
Privileged
Unrestricted. Use only for system namespaces that truly need host access, with tight RBAC.
Baseline
Blocks known-dangerous host sharing while remaining compatible with most common images.
Restricted
Hardening default: non-root, drop ALL capabilities, no hostPath, seccomp RuntimeDefault or stricter.
Version pin
Profiles evolve. Pin latest or a specific version so upgrades do not surprise enforce.
Restricted fields that usually matter
| Field / practice | Restricted expectation | If you need otherwise |
|---|---|---|
| runAsNonRoot / runAsUser | Must not run as UID 0 | Fix the image USER; do not lower the namespace |
| capabilities | Drop ALL; add back only NET_BIND_SERVICE if required | Dedicated privileged namespace with owners |
| hostPath / host* namespaces | Forbidden | Node agent DaemonSet in an exempt system namespace |
| seccompProfile | RuntimeDefault or Localhost, not Unconfined | Document the extra syscalls; prefer a custom profile |
| privileged: true | Forbidden | Almost never for apps; treat as break-glass |
Pod Security rollout checklist
- Label new application namespaces Restricted enforce from day one.
- On existing namespaces, start with warn+audit, fix controllers, then switch enforce.
- Keep kube-system and CNI/CSI namespaces on Privileged only with ClusterRoleBindings that match.
- Reject mutating webhooks that inject hostPath or privileged into Restricted namespaces.
- Build images as non-root with a writable emptyDir for temp files so Restricted is the easy path.
- Version-pin the profile and test Kubernetes upgrades against enforce, not only warn.
- Do not use Privileged as a way to skip image hygiene for a single broken container.
- Combine with NetworkPolicy and runtime patches; Pod Security is spec policy, not a CVE shield.
The practical takeaway
Pod Security is Kubernetes’ namespace-level admission for Pod specs. Restricted is the profile that makes container escape require a real runtime or kernel bug instead of a YAML field.
Enforce it on application namespaces, exempt system pods explicitly, and fix images that still need root. Warn mode without enforce is a report, not a control.
Related security terms
Kubernetes Admission Controller
Pod Security Admission is a built-in admission plugin in that pipeline.
Container Escape
The outcome Pod Security is designed to make much harder.
Namespace Isolation
Profiles are applied per Kubernetes namespace, not per cluster only.
Kubernetes RBAC
RBAC can still allow create pods; Pod Security constrains the spec they may create.
Container Runtime
Admission refuses dangerous specs so the runtime is never asked to start them.
Frequently asked questions
What is Pod Security in simple terms?
It is a cluster rulebook for Pod specs. A namespace labeled Restricted will reject privileged containers, hostPath, and running as root—even if RBAC lets you create Pods.
What happened to PodSecurityPolicy (PSP)?
PSP was removed. Pod Security Admission plus the Pod Security Standards replaced it with simpler namespace-level profiles. Some platforms still add Gatekeeper or Kyverno on top.
What are Privileged, Baseline, and Restricted?
Privileged allows known hardening bypasses. Baseline blocks the most dangerous host sharing. Restricted is the hardening profile: non-root, drop capabilities, no hostPath, seccomp required.
Does Restricted break my app?
Apps that need root, bind to ports below 1024 without capabilities, or write to the container rootfs may fail. Fix the image (non-root USER, writable emptyDir) rather than lowering the whole namespace.
Is enforce the only mode?
No. warn and audit let you see violations before enforce. Use them as a migration, then enforce so warn does not become the permanent setting.
Can a webhook override Pod Security?
Mutating webhooks run before validation. A webhook that injects privileged fields can still be caught by Restricted. Do not run mutating webhooks that re-open hostPath in production namespaces.
Does Pod Security stop runtime CVEs?
No. It reduces the spec-level breakouts. Kernel and runc patches remain mandatory.
References
Explore authoritative guidance and frameworks related to pod security.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.