Kubernetes Pod Security Admission Management

Kubernetes Pod Security Admission Management is the practice of configuring and operating the built-in PodSecurity admission controller, which enforces the Pod Security Standards — privileged, baseline, and restricted — at the namespace level using labels rather than a separate cluster-scoped policy object. It replaced the deprecated PodSecurityPolicy mechanism as the standard, built-in way to enforce baseline pod-level security configuration across a cluster.

The Pod Security Standards

privileged

The privileged standard is fully unrestricted and imposes no additional requirements beyond what the API itself already allows, appropriate only for namespaces running trusted, cluster-level infrastructure components that genuinely need broad host access, such as certain networking or storage plugins.

baseline

The baseline standard blocks known privilege escalation paths — disallowing privileged containers, host namespaces (hostPID, hostIPC, hostNetwork), and dangerous capabilities — while remaining permissive enough to run most common containerized applications without modification.

restricted

The restricted standard applies current pod hardening best practices on top of baseline, requiring runAsNonRoot, disallowing privilege escalation, dropping all capabilities by default, and requiring a defined seccomp profile, representing the strictest of the three standards.

Configuring Enforcement via Namespace Labels

The Three Label Modes

Each standard can be applied in one of three modes, expressed through distinct label keys: enforce rejects non-compliant pods outright, audit allows them but records a violation in the audit log, and warn allows them but returns a warning to the client. All three can be set simultaneously, at the same or different standards, on the same namespace.

apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

Version Pinning

The -version suffix on each mode's label (enforce-version, audit-version, warn-version) pins enforcement to a specific Kubernetes minor version's definition of the standard, which matters because the precise set of restrictions each standard enforces has evolved across releases; pinning avoids an unplanned tightening of enforcement purely as a side effect of a cluster upgrade.

Rolling Out Pod Security Standards

Staged Adoption Using warn and audit

Applying warn and audit at the target standard before switching to enforce reveals which existing workloads in a namespace would be rejected, without actually blocking them, giving teams a concrete list of non-compliant pods to remediate before enforcement is turned on.

kubectl label namespace payments \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted
kubectl apply -f existing-deployment.yaml --dry-run=server

Namespace-by-Namespace Rollout

Because enforcement is configured per namespace, a cluster can migrate incrementally — tightening the most sensitive or externally-facing namespaces to restricted first, while other namespaces remain at baseline until their workloads are ready — rather than requiring a single cluster-wide cutover.

Exemptions

Namespace, User, and RuntimeClass Exemptions

The PodSecurity admission controller supports exemptions configured at the API server level (not through namespace labels) for specific namespaces, specific users, or specific RuntimeClass names, intended for narrowly justified cases — a cluster-level monitoring agent that genuinely requires elevated privileges, for instance — rather than as a general escape hatch.

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
  configuration:
    exemptions:
      namespaces: ["kube-system"]

Operational Considerations

Interaction With Existing Workloads

Applying enforce to a namespace only affects new pod creations and updates going forward; already-running pods that predate the label are not retroactively evaluated, meaning enforcement alone does not guarantee every pod currently running satisfies the standard until those workloads are next redeployed.

Complementing With Additional Policy

Because the Pod Security Standards cover a fixed, well-known set of concerns, organizations with additional requirements — specific label conventions, image provenance, custom resource limits — typically layer a policy engine like Kyverno or OPA Gatekeeper alongside PodSecurity rather than attempting to express those requirements through Pod Security Standard labels alone.