Pod Security Admission: KCSA practice questions

Pod Security Admission is the built-in admission controller that enforces the Pod Security Standards. It replaced PodSecurityPolicy, which was deprecated in Kubernetes v1.21 and removed in v1.25. The standards define three levels. Privileged is unrestricted and allows known privilege escalations. Baseline is minimally restrictive: it blocks known privilege escalations while still admitting a default Pod. Restricted is heavily restricted and follows current Pod hardening practice.

Configuration happens with namespace labels, so restrictions apply per namespace when Pods are created. Each label has the form pod-security.kubernetes.io/<MODE>: <LEVEL>, where the mode is enforce, audit or warn. Enforce rejects violating Pods, audit adds an annotation to the audit log event, and warn returns a warning to the user; in the latter two cases the Pod is still admitted. A namespace can use any or all modes at once, each with a different level, and an optional -version label pins the policy to a given Kubernetes release. Audit and warn are also applied to workload resources such as Deployments, but enforce applies only to the resulting Pod objects, so a non-compliant Deployment can be accepted and then fail to create Pods. Exemptions can be configured for usernames, runtime class names and namespaces.

What the levels check maps directly to securityContext fields. Baseline forbids privileged containers, sharing host namespaces through hostNetwork, hostPID and hostIPC, hostPath volumes, and adding capabilities beyond a default set. Restricted additionally requires runAsNonRoot: true, forbids runAsUser 0, requires allowPrivilegeEscalation: false, requires dropping ALL capabilities (only NET_BIND_SERVICE may be added back), and requires an explicit seccomp profile such as RuntimeDefault. These settings live in the container securityContext (capabilities.add and capabilities.drop, privileged, readOnlyRootFilesystem) or at Pod level (runAsUser, runAsNonRoot, fsGroup, seccompProfile).

The individual fields are worth knowing in their own right. allowPrivilegeEscalation controls the no_new_privs flag, which stops a process from gaining more privileges than its parent, for example through a setuid binary; if unset it defaults to true, and it cannot be false for a privileged container or one with CAP_SYS_ADMIN. readOnlyRootFilesystem mounts the root filesystem read-only, so an attacker cannot modify binaries or drop tools into the image. Setting automountServiceAccountToken: false on a Pod or ServiceAccount keeps API credentials out of workloads that do not need them, and the Pod setting takes precedence. Applying a level to a namespace does not change Pods that already run there; it is checked when Pods are created.

Pod Security Admission covers only these predefined checks. Rules beyond these predefined checks need a separate mechanism, such as a third-party admission plugin you deploy and configure yourself, which is the other replacement the PodSecurityPolicy removal notice names.