Wiki · Concept · Last reviewed June 25, 2026

Kubernetes Pod Security Admission

Kubernetes Pod Security Admission is the built-in admission controller that turns Pod Security Standards into namespace-level enforcement, audit, and warning behavior.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: Kubernetes, Pod Security Admission, Pod Security Standards, admission control, AI governance

Definition

Kubernetes Pod Security Admission, or PSA, is the built-in validating admission controller that checks new pods against the Pod Security Standards allowed for the namespace where the pod would run. Kubernetes documents the feature as stable from v1.25 and describes the PodSecurity admission controller as checking new pods before admission based on the requested security context and the namespace's permitted standards.

The key distinction is that Pod Security Standards define the profiles, while Pod Security Admission applies them at admission time. The profiles are Privileged, Baseline, and Restricted. Privileged is intentionally unrestricted, Baseline blocks common privilege escalations while preserving broad workload compatibility, and Restricted follows stronger pod-hardening practices.

How It Works

PSA is configured through namespace labels. For each namespace, operators can set pod-security.kubernetes.io/enforce, pod-security.kubernetes.io/audit, and pod-security.kubernetes.io/warn. Each mode can point to one of the three profiles, and optional version labels such as pod-security.kubernetes.io/enforce-version can pin checks to a Kubernetes minor version instead of floating with latest.

The three modes have different consequences. enforce rejects pods that violate the selected profile. audit allows the request but adds an audit annotation. warn allows the request but returns a user-facing warning. Kubernetes also applies audit and warning behavior to workload resources with pod templates, such as Deployments and Jobs, so violations can be noticed before the controller creates pods. Enforcement is applied to the resulting pod objects.

Administrators can also configure explicit exemptions. Kubernetes names three exemption dimensions: usernames, RuntimeClass names, and namespaces. Exempted requests skip enforce, audit, and warn behavior, which makes each exemption a governance object rather than a small convenience.

Agent Context

AI infrastructure often turns abstract agency into pod creation. A coding worker, browser runner, notebook job, model server, evaluation harness, vector store, or tool gateway may all be a Kubernetes pod behind the interface. PSA is relevant because those pods can ask the host for dangerous powers: host namespaces, privileged containers, hostPath volumes, extra Linux capabilities, or disabled hardening fields.

A platform running agent workloads might require Restricted namespaces for untrusted code execution, Baseline for ordinary internal tool services, and Privileged only for carefully reviewed infrastructure namespaces. That pattern does not certify model behavior. It narrows what the deployment can ask the cluster to grant before the workload starts.

Governance Use

A useful PSA record should capture namespace, labels, mode, profile level, version pin, workload owner, service account, pod template source, admission result, audit annotation, warning text, rejected field, exception reason, reviewer, review date, and rollback path. For AI systems, the same record should connect the pod to the model, tool, agent, evaluation, or data pipeline that made the pod meaningful.

Rollout discipline matters. The Kubernetes namespace-label task recommends dry-run evaluation for security profile changes because checks can show how existing pods would be treated without changing policy. In practice, a governed rollout starts with warn and audit, reviews violations, fixes manifests, documents exceptions, and only then turns on enforcement where the service can tolerate it.

Limits

PSA is not a complete sandbox. It does not verify image provenance, inspect a software bill of materials, restrict network egress, grant or deny API permissions, control secrets use, monitor runtime drift, or review generated content. It does not decide whether an agent should be allowed to spend money, send email, write code, or call an external API.

It also only covers the cluster paths where the admission controller is enabled and namespace labels are correctly maintained. Privileged namespaces, exemptions, separate clusters, static pods, host-level services, and non-Kubernetes automation can sit outside the control. The right governance posture is to name the uncovered surface and pair PSA with RBAC, NetworkPolicy, admission policy, signed artifact checks, runtime logs, workload identity, and human approval for consequential actions.

Source Discipline

Claims about PSA should cite Kubernetes documentation on Pod Security Admission, Pod Security Standards, namespace-label enforcement, admission controllers, security contexts, and Linux kernel constraints. Claims about AI are deployment inferences: PSA governs Kubernetes pod admission, and the AI relevance follows when model and agent infrastructure is deployed as pods.

Do not present PSA as proof of safety. It is a narrow control over pod specification privilege. Its strength is that it moves part of the decision from informal operator memory into a repeatable admission rule.

Spiralist Reading

Spiralism reads Pod Security Admission as a gate where infrastructure speaks before automation becomes action. The pod asks for powers. The namespace answers with a rule.

That answer is modest, but modest controls matter. A system that records why it rejected a privileged pod is easier to govern than one that discovers the privilege only after the incident report.

Sources

Return to Wiki