Kubernetes Pod Security Admission: Enforcing Baseline and Restricted

September 28, 2026 Khimananda Oli 8 min read DevOps

By Khimananda Oli | Last reviewed: September 2026

Misconfigured pods remain the leading cause of container escapes and lateral movement in production clusters. Kubernetes Pod Security Admission: Enforcing Baseline and Restricted profiles provides a native, declarative mechanism to prevent these vulnerabilities at the API server level without external webhooks. This built-in controller replaced the deprecated PodSecurityPolicy in v1.25 and is now the standard for securing workloads across managed and self-hosted environments. Understanding how to correctly apply these standards is essential for any team managing sensitive data or compliance-bound infrastructure.

Quick answer: Kubernetes Pod Security Admission enforces Baseline and Restricted profiles via namespace labels. Set pod-security.kubernetes.io/enforce: baseline to block known privilege escalations, or use restricted for strict hardening. Apply labels to namespaces, not individual pods, to ensure consistent admission control across all workloads in that scope.

Kubernetes Pod Security Admission intercepts pod creation requests at the API server, validating them against namespace-level profile labels before persistence.

What are the three Pod Security Standards levels?

The Pod Security Standards (PSS) define three distinct policies that map directly to the pod-security.kubernetes.io label keys. Understanding the hierarchy is critical because each level includes all restrictions from the previous one while adding stricter controls. These are not arbitrary categories; they represent graduated security postures validated by the Kubernetes SIG-Security working group.

Privileged: Unrestricted access

This level applies no restrictions and should only be used for system namespaces like kube-system where core components require host access. Never apply this to application workloads. In my experience auditing clusters for SOC 2 compliance, finding application pods in privileged namespaces is an immediate critical finding that requires remediation within 24 hours.

Baseline: Preventing known escalations

The Baseline profile blocks the most dangerous privilege escalation vectors while maintaining compatibility with most applications. It prohibits hostNetwork, hostPID, hostIPC, privileged containers, and unsafe capabilities like SYS_ADMIN. Most well-written applications deploy successfully under Baseline without modification. This is your default target for general-purpose namespaces hosting internal services, databases, and batch jobs.

Restricted: Hardened multi-tenant security

Restricted enforces current pod hardening best practices. Beyond Baseline restrictions, it mandates non-root execution, read-only root filesystems, dropping ALL capabilities, and explicit seccomp profiles. This level is mandatory for untrusted code, multi-tenant platforms, and compliance-sensitive workloads handling PII or financial data. Expect to modify Dockerfiles and deployment manifests when adopting Restricted; plan this as a deliberate engineering effort, not a flip-switch.

Control	Privileged	Baseline	Restricted
Host Namespaces	Allowed	Blocked	Blocked
Privileged Containers	Allowed	Blocked	Blocked
Capabilities	All allowed	Only NET_BIND_SERVICE addable	Must drop ALL, only NET_BIND_SERVICE addable
Run As Non-Root	No requirement	No requirement	Required (container or pod level)
Read-Only Root FS	No requirement	No requirement	Recommended (enforced in some variants)
Seccomp Profile	No requirement	No requirement	RuntimeDefault or Localhost required
Volume Types	All allowed	Safe subset only	Safe subset only

How do you configure namespace labels for enforcement?

Pod Security Admission operates exclusively at the namespace level. You cannot apply PSA labels to individual pods or deployments. This design choice simplifies policy management but requires deliberate namespace strategy. For teams using GitOps with tools like ArgoCD, namespace labels should be managed declaratively in your repository alongside workload manifests.

Applying enforcement labels

Use kubectl label to set the enforce mode. The label key follows the pattern pod-security.kubernetes.io/{mode} where mode is enforce, audit, or warn. Always start with warn or audit before switching to enforce to identify violations without breaking production.

<!-- Enable Baseline enforcement on the 'backend' namespace -->
kubectl label ns backend \
  pod-security.kubernetes.io/enforce=baseline \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/audit=restricted \
  --overwrite

This configuration enforces Baseline immediately while warning developers when their pods violate Restricted standards. The audit label ensures violations appear in API server audit logs even if they pass enforcement, providing visibility for future hardening efforts. I recommend this exact pattern for teams transitioning from legacy PSP configurations.

Version pinning for stability

You can pin labels to specific Kubernetes versions using the format pod-security.kubernetes.io/enforce-version=v1.31. This prevents unexpected breakage during cluster upgrades when PSS definitions evolve. Pin versions in production; track latest in staging to validate compatibility before upgrading pins. Unpinned labels default to the cluster's current version, which changes during upgrades.

Why should you run Baseline in audit mode first?

Enabling enforce mode without prior validation will reject legitimate workloads and cause outages. Audit mode logs violations to the API server audit log without blocking pod creation, giving you a safe observation window. Warn mode returns warnings to kubectl users but also does not block. Use both simultaneously during your transition period.

Label target namespaces with audit and warn modes only. Set pod-security.kubernetes.io/audit=baseline and pod-security.kubernetes.io/warn=baseline. Do not set enforce yet.
Collect violation data for 7–14 days. Parse audit logs for pod-security.kubernetes.io annotations. Tools like ELK Stack or Loki can aggregate these efficiently. Identify which deployments, Helm charts, or operators generate violations.
Remediate violations systematically. Fix Dockerfiles to run as non-root, update Helm values to drop capabilities, adjust operator configurations. Document exceptions that genuinely require elevated privileges.
Re-validate in staging. Deploy fixed manifests to a staging cluster with enforce mode enabled. Confirm zero rejections over a full release cycle including rollbacks and scaling events.
Promote enforce to production. Add the enforce label only after staging validation passes. Keep audit and warn labels active indefinitely for continuous monitoring.

This phased approach mirrors how we handle RBAC policy changes in regulated environments. Skipping the audit phase is the single most common mistake I see teams make when adopting PSA. The cost of a two-week observation window is trivial compared to debugging rejected pods during a production incident.

Four-phase rollout for Kubernetes Pod Security Admission ensuring zero-downtime adoption through progressive enforcement.

How do you handle legitimate exceptions safely?

Some workloads genuinely require elevated privileges. Monitoring agents, CNI plugins, storage drivers, and legacy applications may need capabilities or host access that Baseline or Restricted prohibits. PSA provides namespace-level exemptions for exactly this scenario, but misuse creates security gaps wider than the original problem.

Using exemption labels correctly

Add pod-security.kubernetes.io/exempt/runtimeclasses or user/service account exemptions to bypass specific checks. Prefer RuntimeClass exemptions over user exemptions because they tie privileges to a specific runtime configuration rather than an identity that could be compromised or reused elsewhere.

<!-- Exempt the 'monitoring-agent' service account from Restricted enforcement -->
kubectl label ns observability \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/exempt/serviceaccounts=monitoring-agent \
  --overwrite

Document every exception

Maintain a registry of all PSA exemptions with justification, owner, review date, and compensating controls. During SOC 2 audits, reviewers will request this documentation. Undocumented exemptions are treated as control failures. I store exemption records alongside namespace manifests in Git so they undergo the same code review process as workload changes. Link each exemption to a ticket tracking its eventual removal or permanent justification.

Isolate exempt workloads

Never mix exempt and non-exempt workloads in the same namespace. Create dedicated namespaces like system-agents or legacy-apps for workloads requiring exemptions. This containment limits blast radius if an exempt pod is compromised and makes audit scoping straightforward. Combine with NetworkPolicies to restrict lateral movement from exempt namespaces into sensitive application tiers.

How does Pod Security Admission compare to OPA and Kyverno?

Teams often ask whether PSA replaces policy engines like OPA Gatekeeper or Kyverno. The answer depends on your requirements. PSA covers pod-level security fields natively with zero operational overhead. External engines handle everything else: image registries, resource quotas, label conventions, ingress rules, and custom business logic. They complement PSA; they do not replace it.

PSA handles pod security natively while OPA and Kyverno cover broader policy needs; production clusters typically run both.

For teams just starting their security journey, enable PSA Baseline enforcement first. It delivers immediate value with no infrastructure dependencies. Add OPA or Kyverno later when you need custom policies beyond pod security fields. For organizations already running external engines, keep PSA enabled as a defense-in-depth layer. Defense in depth means multiple independent controls covering the same risk; removing PSA because OPA exists violates this principle. Refer to the comprehensive Kubernetes security guide for layered hardening strategies beyond admission control.

Securing Workloads Through Progressive Enforcement

Kubernetes Pod Security Admission provides the foundation for secure-by-default clusters, but adoption success depends entirely on your rollout discipline. Start with audit mode, fix violations methodically, validate in staging, then enforce in production. Document every exception and review them quarterly. Combine PSA with network segmentation, secrets management, and observability to build defensible infrastructure that passes audits and resists compromise. If your team needs hands-on guidance implementing PSA across existing clusters or designing a compliance-ready security posture, reach out to discuss your specific environment.

Frequently Asked Questions

Baseline prevents known privilege escalations while allowing default configurations. Restricted enforces strict hardening best practices like running as non-root and dropping all capabilities, requiring significant application refactoring for legacy workloads to comply successfully in production clusters.

PSA is built into the kube-apiserver and enabled by default in Kubernetes 1.25+. You activate enforcement by applying labels to namespaces rather than installing external controllers or modifying admission webhook configurations manually.

Yes. Apply specific pod-security.kubernetes.io labels per namespace to set distinct enforce, audit, and warn levels. This allows mixing Baseline for system components and Restricted for user workloads within the same cluster effectively.

No. PSA handles standardized baseline controls natively with zero latency. Policy engines remain necessary for custom compliance rules, image registry allowlisting, and complex organizational policies that exceed the three fixed PSA standard definitions.

The API server rejects the admission request immediately with a descriptive error message. The pod never schedules or starts, preventing insecure workloads from running while providing actionable feedback to developers for remediation.

Set the enforce label to Privileged while configuring audit and warn labels to Restricted. Monitor audit logs and warning responses for violations over several days before switching enforcement, ensuring teams have time to fix issues safely.

Baseline blocks dangerous capabilities like NET_RAW, SYS_ADMIN, and ALL while permitting safe defaults. Containers must explicitly drop added capabilities beyond the default set to pass validation during admission control checks.

No. Restricted mode forbids hostNetwork, hostPID, and hostIPC access entirely. Workloads requiring direct host resource access must use Baseline or Privileged standards in separate namespaces with appropriate isolation boundaries.

Restricted mode mandates seccomp RuntimeDefault or Localhost profiles. Ensure your RuntimeClass configuration supports these profiles; otherwise, pods fail admission even if other security constraints are satisfied correctly in manifests.

No. PSA evaluates pod specs at admission time regardless of RBAC permissions. Even cluster-admin users cannot create non-compliant pods in enforced namespaces without first updating namespace labels or modifying workload specifications.

Frequent failures include missing securityContext.runAsNonRoot fields, undefined capability drops, writable root filesystems, and absent seccomp profiles. Audit logs provide exact field paths causing rejection for targeted manifest corrections.

Negligible. PSA runs as compiled-in admission logic within kube-apiserver without external calls. Benchmarks show sub-millisecond latency increases compared to webhook-based alternatives that require network round trips for every pod creation.

Label exempted namespaces with pod-security.kubernetes.io/exempt=privileged or configure kube-apiserver flags during bootstrap. System namespaces like kube-system typically require exemptions for core components that need elevated host privileges.

Yes. All container types within a pod spec undergo identical security standard evaluation. Init containers, sidecars, and debug containers must each satisfy the namespace enforcement level independently to pass admission.

Consult the Kubernetes documentation Pod Security Standards page and release notes for your specific version. Community benchmarks and CNCF security whitepapers also provide updated migration patterns reflecting current ecosystem tooling and runtime behaviors.