patternbashkubernetesMajor
Pod Security Standards: enforce container security posture
Viewed 0 times
Kubernetes 1.25+ (PSP removed)
pod security standardspsspsprestrictedbaselineprivilegedrunasnonrootallowprivilegeescalationseccompcapabilitieskyvernoopa
Error Messages
Problem
Pods run as root by default or request privileged mode, creating security risks. The deprecated PodSecurityPolicy (PSP) was removed in Kubernetes 1.25.
Solution
Use Pod Security Standards (PSS) via namespace labels. Three built-in profiles: privileged, baseline, restricted.
Restricted profile requires:
# Label a namespace to enforce the restricted profile
kubectl label namespace production \
pod-security.kubernetes.io/enforce=restricted \
pod-security.kubernetes.io/enforce-version=latest \
pod-security.kubernetes.io/warn=restricted \
pod-security.kubernetes.io/audit=restrictedRestricted profile requires:
runAsNonRoot: trueallowPrivilegeEscalation: falseseccompProfile: RuntimeDefaultorLocalhostcapabilities: drop: [ALL]
securityContext:
runAsNonRoot: true
runAsUser: 1000
allowPrivilegeEscalation: false
seccompProfile:
type: RuntimeDefault
capabilities:
drop: ["ALL"]Why
Pod Security Standards replace PSP with a simpler, label-based enforcement model built into the API server admission controller. Restricted is the highest security profile aligned with pod hardening best practices.
Gotchas
- PSP was removed in Kubernetes 1.25 — migrate to PSS or a policy engine like OPA/Kyverno
- warn mode labels emit warnings but do not block pod creation — useful for gradual migration
- Many off-the-shelf Helm charts do not comply with the restricted profile — check with
--dry-runbefore enforcing - Privileged containers (needed for some CNI plugins and node-level DaemonSets) go in the kube-system namespace which typically has privileged or baseline enforcement
Context
Hardening Kubernetes workload security in production namespaces
Revisions (0)
No revisions yet.