Apply Pod Security Admission, the privileged/baseline/restricted standards, namespace labels, runAsNonRoot, and dropped capabilities
0 / 5 completed
1 / 5
What replaced PodSecurityPolicy in modern Kubernetes?
Pod Security Admission (PSA): PodSecurityPolicy was deprecated and removed; PSA is the built-in successor. It enforces the three Pod Security Standards levels by reading namespace labels, requiring no external webhook for the basic policy enforcement that PSP previously provided.
2 / 5
What are the three Pod Security Standards levels?
Pod Security Standards:privileged is fully unrestricted; baseline prevents known privilege escalations while staying broadly compatible; restricted enforces hardening best practices like running as non-root and dropping capabilities. You apply a level per namespace to match its risk tolerance.
3 / 5
How are PSA levels applied to a namespace?
PSA labels: set pod-security.kubernetes.io/enforce=restricted (blocks violating pods), plus /warn and /audit variants for warnings and audit logging. A matching ...-version label pins the standard's version. The three modes let you roll out a stricter level by first warning/auditing before enforcing.
4 / 5
In the securityContext, what does runAsNonRoot: true enforce?
runAsNonRoot: in the pod or container securityContext, this requires the process to run as a non-zero UID. If the image is configured to run as root and no runAsUser overrides it, the container fails to start. Running as non-root is a core requirement of the restricted standard and limits breakout blast radius.
5 / 5
Why drop Linux capabilities and set readOnlyRootFilesystem in hardened pods?
Capabilities & read-only root:capabilities: { drop: ["ALL"] } removes elevated kernel privileges (adding back only specifics like NET_BIND_SERVICE if required). readOnlyRootFilesystem: true stops a compromised process from writing to the image, forcing writable data into explicit mounted volumes. Both are recommended by the restricted profile to minimise attack surface.