Pod Security Admission (PSA) is the built-in Kubernetes admission controller that enforces the Pod Security Standards (PSS), a set of predefined security profiles that constrain what a pod is allowed to do. It became stable in Kubernetes 1.25, at which point its predecessor PodSecurityPolicy (PSP) was simultaneously removed. Where PSP was a complex, cluster-scoped object requiring deep RBAC wiring and prone to misconfiguration, PSA is deliberately simpler: it is always enabled, requires no CRDs or RBAC setup, and is configured entirely through namespace labels. The trade-off for that simplicity is that PSA is opinionated and coarse-grained — it enforces fixed profiles rather than arbitrary custom rules, and its granularity is the namespace rather than the individual workload or service account. Teams needing finer-grained policy beyond what PSA offers typically combine it with a policy engine such as Kyverno or OPA Gatekeeper.
PSA enforces three fixed Pod Security Standards profiles, each a named set of controls over the pod spec. Privileged imposes no restrictions and is intended only for system-level infrastructure components that genuinely require full host access — CNI plugins, storage drivers, node agents. Baseline blocks the most commonly exploited privilege escalation vectors — privileged containers, hostNetwork/hostPID/hostIPC sharing, dangerous volume types, and certain capabilities — while remaining compatible with most applications that do not require special privileges. Restricted applies the full set of current pod hardening best practices on top of Baseline: non-root user required, root filesystem read-only encouraged, all capabilities dropped with only specific ones allowable, a seccomp profile mandatory. Each profile is versioned by Kubernetes minor release, allowing administrators to pin a namespace to the policy as it existed at a given version and prevent unexpected tightening during cluster upgrades. Enforcement is applied independently per namespace across three modes: enforce (pod is rejected), audit (violation is logged to the audit log but pod is admitted), and warn (a user-facing warning is returned but the pod is admitted). A namespace can combine modes and levels independently — the standard migration pattern is to set enforce=baseline, audit=restricted, warn=restricted, which blocks clear violations immediately while surfacing restricted-level gaps without breaking workloads.
PSA operates as a pure validating admission controller — it inspects the pod spec and either admits or rejects it, but does not mutate the pod. This is the fundamental architectural difference from SCCs on OpenShift, which are both validating and mutating: an SCC can inject missing security context fields (a UID range, an SELinux label) into a pod that did not specify them, making the pod compliant without any change to the workload manifest. PSA will simply reject a non-compliant pod and return an error. Exemptions from PSA enforcement can be configured at the cluster level for specific usernames, namespace names, and RuntimeClasses — used to exclude infrastructure namespaces and privileged system components without labelling every individual namespace. On OpenShift, PSA and SCCs coexist with a label synchronisation component that automatically sets PSA namespace labels to match the effective privilege level of the SCCs bound to service accounts in that namespace, preventing conflicts between the two enforcement layers.