Pod Security Admission

PSA replaces PSP. The migration.

Modes

Pod Security Admission (PSA) replaced the deprecated PodSecurityPolicy. PSA enforces Pod Security Standards at admission time; pods that violate the standards are rejected. The discipline is configuring PSA correctly: choosing the right mode and level per namespace.

What modes PSA supports:

• enforce, audit, warn per namespace.: PSA supports three modes per namespace. Enforce blocks non-conforming pods; audit logs violations; warn surfaces warnings to the user. The modes can combine per namespace.
• Test with audit; switch to enforce.: The standard rollout is audit first. Audit mode reveals violations without blocking; the team fixes the violations; then enforce is enabled.
• Audit mode is non-disruptive.: Audit produces logs; pods that violate run anyway. The team observes; the workloads continue; the data drives remediation.
• Warn mode user-facing.: Warn produces messages to the user submitting the pod. Engineers see the warning when they kubectl apply; they fix without the violation reaching production.
• Combine for layered effect.: A namespace might be enforce at baseline level, audit at restricted level. The combination produces immediate enforcement of basics and observation of stricter requirements.

The modes provide flexibility. The team chooses what fits the namespace's stage of adoption.

Levels

The Pod Security Standards levels (privileged, baseline, restricted) determine what is enforced. Each level has progressively stricter requirements; the choice matches the namespace's role.

• privileged.: No restrictions. System namespaces (kube-system) and explicit exceptions use this level. Most workloads should not run at privileged.
• baseline.: Reasonable defaults. Privileged containers, host network, host paths blocked. Most application namespaces fit this level without code changes.
• restricted.: Strict enforcement. Drop all capabilities, run as non-root, seccomp profiles required. New workloads should target this; existing workloads need refactoring.
• Baseline default.: Most teams default new namespaces to baseline. The level provides meaningful security with minimal accommodation.
• Restricted for hardened.: Critical workloads, customer-data workloads, regulated workloads benefit from restricted. The level provides defense in depth; the workload's compromise has bounded impact.

Levels match the security requirement. Higher levels for higher stakes; the choice is per-namespace.

Migrate

The migration to PSA is incremental. Per-namespace rollout; production last; catch the egregious patterns before they reach production.

• Per namespace.: The migration moves namespace by namespace. Each namespace is configured; observed; verified; the next namespace follows.
• Prod last.: Production is the last namespace migrated. The team has experience by then; the patterns are known; the production migration is informed.
• Catches the egregious before it ships.: The migration surfaces the egregious patterns. Privileged containers in production where they should not be; host paths used inappropriately; host network where pod network would suffice. The migration produces visibility; the visibility drives fixes.
• Document each namespace's level.: The team documents which level applies where. The documentation supports auditors and new team members; the discipline is preserved.
• Quarterly review.: The PSA configuration is reviewed quarterly. Are the levels still appropriate? Should any namespace harden? The review keeps the configuration current.

Pod Security Admission is one of those Kubernetes security disciplines that pays off across many namespaces. Nova AI Ops integrates with cluster admission data, surfaces PSA violations and configurations, and produces the per-namespace visibility that the security team uses to drive harder defaults over time.