Pod Security Admission

The privileged level is a completely unrestricted policy that allows all known privilege escalations. It is intended for trusted, system-level workloads managed by administrators.

• Permits host namespaces (network, PID, IPC)
• Allows privileged containers with full capabilities
• Accepts hostPath volumes and unrestricted sysctls
• Suitable for logging daemons, CNI plugins, and node agents

This level provides no security restrictions and should never be used for multi-tenant or untrusted workloads.

The baseline level prevents known privilege escalations while allowing the default, minimally specified pod configuration. It is the recommended minimum for most application workloads.

• Blocks host namespaces and hostPath volumes
• Prohibits privileged containers and CAP_SYS_ADMIN
• Restricts hostPort ranges and /proc mount types
• Allows standard volume types (configMap, secret, emptyDir)

Baseline targets the easiest-to-exploit privilege escalations while maintaining broad compatibility with existing deployments.

The restricted level enforces the current best practices for pod hardening, following the Pod Security Standards at the cost of some compatibility. It is required for true multi-tenant environments.

• Requires runAsNonRoot: true and drops all capabilities
• Mandates seccomp profiles (RuntimeDefault or localhost)
• Restricts volume types to projected, downwardAPI, and ephemeral only
• Enforces allowPrivilegeEscalation: false

This level aligns with the restricted Pod Security Standard and is the target for zero-trust cluster architectures.

PSA policies are enforced at the namespace level using well-known labels, providing a declarative model that does not require modifying admission webhook configurations.

• pod-security.kubernetes.io/enforce: Blocks non-compliant pods
• pod-security.kubernetes.io/audit: Logs violations without blocking
• pod-security.kubernetes.io/warn: Returns warnings to the user

Each label accepts a level value (privileged, baseline, restricted) and an optional version (e.g., v1.29) to lock policy definitions to a specific Kubernetes release.

PSA supports fine-grained exemptions for specific users, namespaces, or runtime classes that must bypass policy enforcement. This is critical for infrastructure components.

• Usernames: Exempt specific service account identities
• RuntimeClasses: Exempt pods using a particular container runtime
• Namespaces: Exempt entire namespaces by name

Exemptions are configured in the Pod Security Admission controller configuration and should be audited regularly to prevent privilege creep in system namespaces like kube-system.

Pod Security Admission replaces the deprecated PodSecurityPolicy (PSP) with a simpler, label-based model that does not require creating and binding complex policy objects.

• PSPs were mutating; PSA is purely validating
• PSA policies map directly to the Pod Security Standards
• Use kubectl label to apply policies instead of RBAC bindings
• The kubectl dry-run server flag (--dry-run=server) validates pods against PSA before submission

Migration tools like the PSP Migrator can analyze existing PSPs and generate equivalent namespace labels automatically.

Maps a container's root user (UID 0) to an unprivileged, high-numbered UID on the host. If an agent escapes the container, it does not gain root on the host.

• Eliminates the risk of privilege escalation on container breakout
• Enabled via userns-remap in the container runtime configuration
• A foundational control that Pod Security Admission's RunAsNonRoot enforcement builds upon

A short-lived, disposable execution context created from a known-good image and destroyed after a single agent task. Prevents state contamination and persistent threats.

• Each agent invocation starts from a clean, immutable snapshot
• Eliminates the risk of an attacker persisting across task boundaries
• Works with Pod Security Admission to ensure even ephemeral pods meet baseline security standards