Skip to main content
In this lesson, we’ll dive into Pod Security Admission (PSA) and Pod Security Standards (PSS). Introduced via KEP 2579, PSA replaces Pod Security Policies (PSP) with a safer, simpler, and extensible solution. For advanced checks, you can integrate external tools like OPA Gatekeeper.
The image lists the "Pod Security Requirements" for Kubernetes, including points like validation, safety in clusters, built-in controller, Windows support, API responsiveness, ease of use, and extensibility. It also references KEP 2579 for PSP replacement.

​
Pod Security Admission Overview

PSA is an Admission Controller enabled by default in Kubernetes.
Verify it by inspecting the API server’s enabled plugins: 
kubectl exec -n kube-system kube-apiserver-controlplane -it -- \
  kube-apiserver -h | grep enable-admission-plugins
You should see PodSecurity listed. Configure PSA at the namespace level by adding labels: 
kubectl label namespace <NAMESPACE> pod-security.kubernetes.io/<mode>=<profile>
PSA modes (enforce, audit, warn) and profiles (privileged, baseline, restricted) can be combined to meet your security requirements.

​
Pod Security Standards: Built-in Profiles

PSA offers three out-of-the-box profiles:
ProfileDescriptionUse Case
privilegedUnrestricted; allows all capabilitiesDebugging, system-level tooling
baselineMinimal restrictions; prevents privilege escalationMost standard applications
restrictedStrict hardening; follows best practicesHigh-security or compliance needs
The image is a slide titled "Configure PSA" showing tables that describe modes and profiles for security standards, including actions on violation and policy descriptions.

​
Pod Security Admission Modes

A mode controls PSA’s response to policy violations:
ModeAction on Violation
enforceRejects non-compliant pod creation requests
auditLogs an audit event; allows the pod
warnEmits a user-facing warning; allows the pod
You can combine modes and profiles, for example:
  • warn+restricted — pods are allowed, violations generate warnings
  • enforce+restricted — non-compliant pods are blocked

​
Profile Details

​
Baseline Profile

Designed for ease of adoption, the baseline profile prevents unauthorized privilege escalation while maintaining compatibility.
The image shows a document titled "Baseline Profile" detailing Kubernetes security policies, including restricted fields and allowed values for various configurations. It includes sections on host processes, namespaces, privileged containers, capabilities, host path volumes, host ports, and AppArmor.

​
Restricted Profile

Enforces the latest pod-hardening best practices. Be aware that compatibility issues may arise.
The image shows a slide titled "Restricted Profile" with text detailing Kubernetes security policies, including volume types, privilege escalation, and capabilities. It includes a link to Kubernetes documentation on pod security standards.
The restricted profile may require you to update container images or init scripts to comply with stricter defaults.

​
Privileged Profile

Applies no restrictions; all capabilities are allowed. Use with caution.

​
Applying Profiles to Namespaces

Label your namespaces to enforce specific profiles and modes: 
kubectl label namespace payroll pod-security.kubernetes.io/enforce=restricted
kubectl label namespace hr      pod-security.kubernetes.io/enforce=baseline
kubectl label namespace dev     pod-security.kubernetes.io/warn=restricted
  • In payroll: any pod violating the restricted policy is rejected.
  • In hr: only pods meeting the baseline policy are allowed.
  • In dev: all pods are created, but restricted violations generate warnings.

​
References

Watch Video