Kubernetes Pod Security Admission and Policy Enforcement

Kubernetes Pod Security Admission (PSA) gives platform teams a built-in way to prevent Pods from using risky security settings. It is useful for cluster administrators, security engineers, and application teams that need consistent workload guardrails without writing a custom admission controller. This explainer covers how PSA evaluates requests, how its policy levels differ, and how to introduce enforcement without unexpectedly blocking deployments.

What Is Kubernetes Pod Security Admission?

Pod Security Admission is a validating admission controller in the Kubernetes API server. When a request creates or updates a Pod, PSA checks the Pod specification against the Pod Security Standards selected for its namespace. A namespace can reject violations, report them to the requesting client, or record them in the API audit event.

The Kubernetes documentation for Pod Security Admission describes the built-in controller and its namespace labels. The Pod Security Standards define the policy profiles PSA evaluates. The Kubernetes project maintains the platform and its security behavior; PSA is one control within that broader system, not a separate security product.

PSA is enabled by default in supported Kubernetes control planes, but it does not automatically make every namespace restrictive. An unlabeled namespace uses the privileged policy level, which permits the full range of Pod configurations. Operators must deliberately choose and apply namespace labels to get preventive enforcement.

The Problem Pod Security Admission Solves

A Kubernetes Pod can request host namespaces, privileged containers, added Linux capabilities, or other settings that weaken isolation. A single broad permission may be intentional for a system component, but an accidental setting in an application manifest can expose a node or neighboring workloads to unnecessary risk.

RBAC controls who can submit API requests; it does not generally decide whether a particular Pod specification is safe. Image scanning checks software inside images, while runtime monitoring observes behavior after launch. PSA adds a preventive check at admission time: it can reject Pod configurations that violate a selected baseline before the API server stores the Pod.

That check is intentionally focused. PSA applies a Kubernetes-defined set of Pod restrictions; it does not assess application vulnerabilities, validate image provenance, or replace node security, network policies, or access control. NIST SP 800-190 provides broader guidance for container security across images, runtimes, orchestration, and hosts.

How Pod Security Admission Works

The API server receives a Pod request and runs its configured admission checks. PSA reads the namespace’s policy labels, compares the Pod fields covered by the selected standard, and takes the action configured for each mode. It does not rewrite the Pod to make it compliant: a rejected request must be corrected by its author.

The checks target Pod security settings rather than application behavior. Depending on the profile, they cover settings such as host namespaces, privileged containers, host paths, Linux capabilities, privilege escalation, seccomp, and whether a process may run as root. PSA is therefore predictable: it can evaluate these fields from the submitted object without needing to inspect an image or observe a running process.

Each namespace can configure one or more modes, and those modes can use different policy levels:

PSA also evaluates Pod templates in common workload resources such as Deployments. Warnings and audit results can reveal a noncompliant template, but enforcement is applied when the controller creates the actual Pod. A Deployment object may therefore be accepted while its Pods are rejected and remain unavailable. Plan verification around Pods and controller events, not only whether a workload manifest was accepted.

Namespace labels choose a level for each mode: privileged, baseline, or restricted. Version labels can pin a mode to the Pod Security Standards that shipped with a specific Kubernetes minor version. Pinning avoids a policy’s meaning changing unexpectedly during a cluster upgrade; teams that prefer to track the newest standards can use the latest version instead.

Audit mode depends on the cluster’s API audit pipeline to retain and expose audit events. A policy annotation in an event is useful only if the control plane is configured to record the relevant request and operators can query those records. Warning mode is easier to see during interactive kubectl use, but automated deployment clients may surface warnings differently. Use both signals when assessing a large fleet rather than treating the absence of a terminal warning as proof of compliance.

Policy Levels and Related Controls

The three Pod Security Standards profiles form a progression rather than a set of custom rules:

• Privileged has no restrictions from the standard. It is appropriate only where unrestricted Pod settings are intentional.
• Baseline blocks known privilege-escalation paths while preserving a broader range of ordinary workloads.
• Restricted applies stronger hardening expectations, including controls around privilege escalation, Linux capabilities, user identity, and seccomp.

The table compares PSA with extensible policy tools such as Kyverno and Gatekeeper. These tools can complement PSA, but they introduce different policy and operational choices.

Kubernetes also provides other admission mechanisms, including ValidatingAdmissionPolicy for policies expressed with CEL. Choose the simplest control that matches the requirement: PSA is often a useful baseline, while an additional policy engine should be justified by rules that PSA cannot express. The container security best practices guide discusses adjacent controls such as image hardening, supply-chain checks, and runtime protection.

Real-World Use Cases

Staged hardening: A platform team can begin with warn and audit at restricted in application namespaces, review the reported violations, and then enable enforce after teams have corrected their templates. This makes policy adoption observable rather than relying on a cluster-wide surprise.

Namespace separation: Development, production, and system workloads can use different namespace policies. A tightly controlled namespace can enforce restricted, while a dedicated namespace for a trusted node-level agent can use a carefully reviewed exception or different policy.

Guardrails in GitOps: Teams can store namespace labels alongside application configuration. A continuous delivery controller then reconciles policy and workload changes from version control. The Kubernetes CI/CD and Argo CD guide explains that deployment workflow; PSA provides a final API-side check regardless of which client submits the Pod.

PSA exemptions are configured by cluster operators in the admission configuration, rather than by ordinary namespace labels. Exemptions can match namespaces, usernames, or RuntimeClasses. Keep them narrow and documented: an overly broad exemption can silently remove the protection operators expect.

Getting Started: Apply and Verify a Policy

Use a test cluster first. Create a namespace with restricted enforcement and non-blocking feedback modes:

kubectl create namespace payments

kubectl label --overwrite namespace payments \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/audit=restricted

The namespace labels are the policy interface; there is no separate policy object to install for PSA. For stable behavior through Kubernetes upgrades, add the corresponding *-version labels and set each to a minor version supported by your cluster. Review the upstream standards before changing a pinned version.

For an organization-wide rollout, set policy labels through the namespace provisioning workflow and limit which identities can change them. Begin with warnings and audit results in representative namespaces, group violations by owning team, and test a compliant workload update. Move a namespace to enforce only after teams have updated the source templates. Keep any exemption in the cluster’s reviewed admission configuration, record its owner and purpose, and revisit it as workloads change.

Save this compliant Pod as restricted-pod.yaml. Its security context meets key Restricted profile requirements: it runs as a non-root user, prevents privilege escalation, drops Linux capabilities, and uses the runtime’s default seccomp profile.

apiVersion: v1
kind: Pod
metadata:
  name: restricted-check
  namespace: payments
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: pause
      image: registry.k8s.io/pause:3.10
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL

Submit it as a server-side dry run before creating a real Pod:

kubectl apply --dry-run=server -f restricted-pod.yaml
kubectl get namespace payments --show-labels

To check that enforcement is active, submit a deliberately noncompliant Pod in the same namespace. This example requests privileged mode and should be rejected by the server-side dry run:

apiVersion: v1
kind: Pod
metadata:
  name: privileged-check
  namespace: payments
spec:
  containers:
    - name: pause
      image: registry.k8s.io/pause:3.10
      securityContext:
        privileged: true

kubectl apply --dry-run=server -f privileged-pod.yaml

Expect an admission error that identifies the restricted policy violation. If the request succeeds, confirm that the namespace is correctly labeled, the API server supports PSA, and the request is not covered by an exemption. For a Deployment, inspect the ReplicaSet and namespace events to find Pods rejected after the controller tried to create them:

kubectl get pods -n payments
kubectl get events -n payments --sort-by=.lastTimestamp
kubectl describe replicaset -n payments

Before enforcement in an established namespace, apply warn and audit first, inventory violations, update the workload templates, and then enable enforce. Existing Pods are not automatically evicted when labels change; test newly created Pods and plan a controlled rollout if existing workloads must be recreated under the new policy.

Common Misconceptions

“PSA is a complete container security system.” It only checks fields covered by Pod Security Standards. It does not scan image contents, verify signatures, encrypt secrets, or monitor runtime behavior.

“Adding a label fixes unsafe workloads.” A label selects the rule and its mode. In enforce, noncompliant Pods are rejected, not repaired. Update the source manifests so future rollouts remain compliant.

“A successful Deployment apply proves its Pods passed.” Controllers create Pods after the workload object is stored. Check the resulting Pod status and events; warnings or an accepted Deployment do not guarantee successful Pod admission.

Related Articles

• Kubernetes architecture explained
• Container security best practices
• Kubernetes CI/CD with Argo CD
• Kubernetes operators and extended automation

Changelog

• Initial publication.