| name | implementing-kubernetes-pod-security-standards |
| description | Pod Security Standards (PSS) define three levels of security policies -- Privileged, Baseline, and Restricted -- enforced by the Pod Security Admission (PSA) controller built into Kubernetes 1.25+. PS |
| domain | cybersecurity |
| subdomain | container-security |
| tags | ["containers","kubernetes","security","pod-security","PSA"] |
| version | 1.0 |
| author | mahipal |
| license | Apache-2.0 |
| nist_csf | ["PR.PS-01","PR.IR-01","ID.AM-08","DE.CM-01"] |
Implementing Kubernetes Pod Security Standards
Overview
Pod Security Standards (PSS) define three levels of security policies -- Privileged, Baseline, and Restricted -- enforced by the Pod Security Admission (PSA) controller built into Kubernetes 1.25+. PSA replaces the deprecated PodSecurityPolicy and provides namespace-level enforcement with three modes: enforce, audit, and warn.
When to Use
- When deploying or configuring implementing kubernetes pod security standards capabilities in your environment
- When establishing security controls aligned to compliance requirements
- When building or improving security architecture for this domain
- When conducting security assessments that require this implementation
Common Misconfigurations & Verification
enforce label missing: namespaces labelled only pod-security.kubernetes.io/audit=restricted and /warn=restricted log and warn but never block - a privileged: true pod still schedules. Confirm enforce is set: kubectl get ns -L pod-security.kubernetes.io/enforce.- Label key typos:
pod-security.kubernetes.io/enforced or a missing mode value is silently ignored by the admission controller; PSA does not error on unknown labels.
enforce-version: latest drift: pinning to latest means an apiserver upgrade can tighten or change checks unexpectedly. Pin a concrete version (e.g. v1.28) for predictable behavior.- PSA can't inspect image contents: it evaluates the pod spec only, so it won't catch a root
USER baked into the image or an unsigned image - layer Gatekeeper/Kyverno for those.
- Workload lives in an exempt namespace: restricted on
production is moot if the deployment actually runs in default/a system namespace; verify the target namespace's labels, not the cluster default.
- Verify before enforcing:
kubectl label --dry-run=server --overwrite ns <ns> pod-security.kubernetes.io/enforce=restricted lists existing violators; then kubectl run test --image=nginx -n <ns> --dry-run=server should be rejected under restricted (nginx runs as root).
Prerequisites
- Kubernetes cluster 1.25+ (PSA GA)
- kubectl configured with cluster-admin access
