Glossary

Pod Security Admission (PSA)

A built-in Kubernetes admission controller that enforces security standards at the namespace level, replacing the deprecated PodSecurityPolicy to restrict privileged container operations.

Get in touch Learn more

Operations room with a large monitor wall for system visibility and control.

KUBERNETES SECURITY

What is Pod Security Admission (PSA)?

Pod Security Admission (PSA) is a built-in Kubernetes admission controller that enforces configurable security standards at the namespace level, replacing the deprecated PodSecurityPolicy (PSP) to restrict privileged container operations.

Pod Security Admission (PSA) is a built-in Kubernetes admission controller that enforces Pod Security Standards at the namespace level. It intercepts pod creation requests and validates their security context against a configured policy, denying pods that violate restrictions on privileged containers, host namespaces, or root-level filesystem access. This mechanism replaces the deprecated PodSecurityPolicy (PSP) with a simpler, label-driven enforcement model.

PSA operates through three graduated policy levels—privileged, baseline, and restricted—applied via namespace labels. The restricted policy, critical for air-gapped AI infrastructure, mandates non-root execution, read-only root filesystems, and drops all Linux capabilities. In disconnected environments, PSA ensures that model-serving containers cannot escape to the host, enforcing a strong security boundary without external policy engines.

Built-in Kubernetes Security

Key Features of Pod Security Admission

Pod Security Admission (PSA) is a built-in admission controller that enforces predefined Pod Security Standards at the namespace level. It replaces the deprecated PodSecurityPolicy (PSP) to provide a simpler, more consistent mechanism for restricting privileged container operations.

Three Security Levels

PSA defines three distinct policy levels that map directly to the Pod Security Standards:

privileged: Unrestricted policy, allowing all known privilege escalations. Suitable for system and infrastructure workloads.
baseline: Minimally restrictive policy that prevents known privilege escalations. Allows the default, minimally specified Pod.
restricted: Heavily restricted policy following Pod hardening best practices, enforcing strict isolation at the cost of some compatibility.

Namespace-Label Driven Enforcement

Enforcement is controlled entirely through namespace labels, eliminating the need for complex RBAC rules or policy bindings. An admission controller watches for these labels and acts accordingly.

pod-security.kubernetes.io/enforce: Rejects any Pod that violates the specified policy level.
pod-security.kubernetes.io/audit: Logs audit events for violations without rejecting the Pod.
pod-security.kubernetes.io/warn: Returns a user-facing warning for violations without rejecting the Pod.

This allows for a gradual rollout from warn to audit to enforce.

Exemptions for System Workloads

PSA provides a mechanism to exempt specific users, runtime classes, or namespaces from policy enforcement. This is critical for infrastructure components that legitimately require privileged access, such as logging daemons or CNI plugins.

Exemptions are configured in the admission controller's configuration file, not through labels. A common pattern is to exempt the kube-system namespace and specific service accounts required for node-level operations.

Versioned Policy Evolution

Pod Security Standards are versioned independently of Kubernetes, allowing the policies to evolve and become more restrictive over time. The restricted policy, for example, may add new controls in a future version.

You can pin a namespace to a specific policy version using the label suffix pod-security.kubernetes.io/enforce-version: v1.26. This ensures that cluster upgrades do not suddenly break existing workloads due to newly added restrictions.

Workload-Level Warnings

When a Pod specification violates the configured policy, PSA returns a detailed, human-readable warning message to the user. This message pinpoints the exact field that caused the violation.

For example, a violation of the restricted profile might return: 'spec.containers[0].securityContext.privileged: Forbidden: privileged containers are not allowed'. This immediate feedback loop helps developers fix security issues before deployment.

Dry-Run Validation

PSA integrates with the kubectl apply --dry-run=server and kubectl auth can-i commands. This allows CI/CD pipelines to validate Pod manifests against the target namespace's security policy before attempting a real deployment.

A typical pipeline step runs kubectl apply --dry-run=server -f pod.yaml and fails the build if the admission controller returns a rejection, shifting security validation left in the development lifecycle.

POD SECURITY ADMISSION

Frequently Asked Questions

Clear, technical answers to the most common questions about enforcing Pod Security Standards in disconnected Kubernetes environments for AI workloads.

Pod Security Admission (PSA) is a built-in Kubernetes admission controller that enforces predefined Pod Security Standards at the namespace level. It operates by intercepting API requests to create or update pods and evaluating the pod's security context against one of three policy levels: privileged, baseline, or restricted. The enforcement is configured via simple namespace labels, such as pod-security.kubernetes.io/enforce: restricted. When a pod specification violates the assigned standard—for example, by requesting host network access under a restricted policy—the admission controller rejects the request with a detailed error message before the pod is persisted to etcd. PSA replaces the deprecated PodSecurityPolicy (PSP) mechanism, offering a simpler, controller-less architecture that requires no RBAC bindings or policy ordering logic, making it especially suitable for air-gapped clusters where operational simplicity is paramount.

Enabling Efficiency, Speed & Accuracy

Intelligent Analysis, Decision & Execution

We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.

Talk to Us

Search across company data

Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.

Useful when people spend too long searching or get different answers from different systems.

Enterprise searchRAGPermissions

Automate internal workflows

Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.

Useful when repetitive work moves across multiple tools and teams.

AI agentsWorkflow automationGovernance

Add AI to products and internal tools

Build assistants, guided actions, or decision support into the software your team or customers already use.

Useful when AI needs to be part of the product, not a separate tool.

AI integrationDecision supportModel routing

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.

Limited slotsGet a Free AI Consultation

How We Work

Custom AI workflows for your Business

One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.

Talk to Us

Pod Security Admission (PSA)

What is Pod Security Admission (PSA)?