What is pod security admission? A Practitioner's Definition

TL;DR - Pod Security Admission is Kubernetes’ built-in way to enforce pod security rules. - It checks pods against namespace-level security standards like Privileged, Baseline, and Restricted. - You’ll encounter it when workloads are denied, warned, or audited for unsafe pod settings.

Definition

Pod Security Admission is a built-in Kubernetes admission controller that evaluates pods and pod-creating workloads against predefined Pod Security Standards. In practice, it helps cluster operators enforce safer defaults at the namespace level without relying on the older PodSecurityPolicy feature.

How it works

Pod Security Admission, often shortened to PSA, runs during the Kubernetes admission process. That means it checks a request before the object is fully accepted by the API server.

At a high level, the workflow is straightforward:

1. A user or controller creates a pod, deployment, job, daemonset, or another workload that results in pods.
2. The Kubernetes API server evaluates the request.
3. Pod Security Admission checks the target namespace labels.
4. Based on those labels, Kubernetes applies one or more Pod Security Standards.
5. The request is either allowed, allowed with warnings, recorded for audit visibility, or rejected.

The key idea is that PSA is namespace-scoped policy enforcement based on standard security profiles. Instead of writing a long custom policy from scratch, you assign a mode and level to a namespace.

The three Pod Security Standards are:

• Privileged: essentially unrestricted, for trusted system workloads or special cases
• Baseline: prevents known risky settings but remains fairly compatible with common apps
• Restricted: the strictest built-in profile, intended for security-focused environments

The three enforcement modes are:

• enforce: rejects non-compliant pods
• warn: allows the request but returns a warning to the client
• audit: allows the request and records audit annotations for visibility

In practice, you apply them with namespace labels like these:

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

This example means:

• pods in prod-apps must meet the restricted standard to be admitted
• Kubernetes will also warn and audit against the baseline version specified

A common rollout pattern is to start with warn and audit, review what would break, then move to enforce.

Technical Notes

You can inspect namespace labels with:

kubectl get ns prod-apps --show-labels

You can label a namespace directly:

kubectl label namespace prod-apps \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=latest \
  pod-security.kubernetes.io/warn=baseline \
  pod-security.kubernetes.io/audit=baseline

A typical denial might happen if a pod tries to run as privileged:

securityContext:
  privileged: true

Or if it uses host namespaces or host path volumes that violate the selected standard.

You may also see warnings like:

Warning: would violate PodSecurity "restricted:latest":
allowPrivilegeEscalation != false,
unrestricted capabilities,
runAsNonRoot != true

That message is your signal that the workload needs hardening before you switch a namespace to enforce.

When you’ll encounter it

Most teams encounter pod security admission in one of four situations.

1. During cluster hardening

If you’re improving Kubernetes security posture, PSA is one of the first native controls you’ll look at. It gives you a built-in guardrail without immediately deploying a separate policy engine.

For SMBs and lean platform teams, this matters because it reduces reliance on custom policy stacks for basic pod-level protections.

2. When migrating away from PodSecurityPolicy

PodSecurityPolicy, or PSP, was deprecated and then removed from Kubernetes. If you previously depended on PSP to control privileged containers, host networking, or unsafe Linux capabilities, PSA is the built-in replacement for standard use cases.

It is simpler than PSP, but also less customizable. That tradeoff is important.

3. When workloads fail to deploy

Application teams often meet PSA when a deployment that worked in one cluster is denied in another. Common triggers include:

• containers running as root
• allowPrivilegeEscalation: true
• added Linux capabilities
• hostNetwork, hostPID, or hostIPC
• privileged mode
• certain volume types

If your CI/CD pipeline applies manifests and suddenly gets admission errors, check namespace pod security labels early in the troubleshooting process.

4. During compliance or multi-tenant operations

In shared clusters, PSA helps ensure one namespace cannot casually run high-risk pod settings just because a developer copied an example from the internet. It is especially useful where different teams have different trust levels.

For example:

• system namespaces may need privileged
• internal development namespaces may use baseline
• production application namespaces may use restricted

Technical Notes

To test whether a manifest is likely to be blocked, use a dry run:

kubectl apply -f deployment.yaml --dry-run=server

To see why a rollout failed:

kubectl describe pod <pod-name>
kubectl get events -n <namespace> --sort-by=.lastTimestamp

A failed admission often appears in events or API responses with wording tied to Pod Security violations.

Related terms

Pod Security Standards

These are the predefined policy levels PSA uses: Privileged, Baseline, and Restricted. Think of PSA as the enforcement mechanism and Pod Security Standards as the rule sets.

Admission controller

An admission controller is a Kubernetes component that intercepts API requests before persistence. PSA is one example of an admission controller.

Namespace labels

PSA is configured using labels on namespaces, not on each pod individually. That design makes broad policy rollout easier, but it also means namespace governance becomes important.

PodSecurityPolicy

PodSecurityPolicy was the older Kubernetes feature for pod security enforcement. It offered more granularity but was considered difficult to use and has been removed from modern Kubernetes versions.

OPA Gatekeeper and Kyverno

These are policy engines often used alongside or instead of PSA when teams need more custom logic. PSA covers standard pod hardening rules; Gatekeeper and Kyverno can enforce more specific organizational requirements.

Security context

A pod or container securityContext defines settings such as user IDs, Linux capabilities, privilege escalation, seccomp, and filesystem behavior. PSA evaluates many of these fields.

Technical Notes

Here is a minimal example of a more compliant container spec for restricted-style environments:

apiVersion: v1
kind: Pod
metadata:
  name: secure-example
spec:
  containers:
    - name: app
      image: nginx:stable
      securityContext:
        allowPrivilegeEscalation: false
        runAsNonRoot: true
        capabilities:
          drop:
            - ALL
      ports:
        - containerPort: 80

This does not guarantee compliance in every cluster version or policy combination, but it shows the kind of safer defaults PSA expects.

Why pod security admission matters

PSA matters because Kubernetes will happily run dangerous pod configurations unless you tell it not to. Without guardrails, developers can unintentionally deploy workloads with excessive privileges, host access, or weak isolation.

For practitioners, the value is simple:

• it raises the default security baseline
• it catches risky pod settings early
• it creates a repeatable namespace-level policy model
• it helps platform teams scale governance without manual review of every manifest

The main limitation is equally important: PSA is intentionally opinionated and not deeply customizable. If you need exception workflows, image policy checks, label requirements, or business-specific controls, you will likely pair it with a broader policy framework.

Bottom line

Pod Security Admission is Kubernetes’ built-in mechanism for enforcing standard pod hardening rules at the namespace level. If you run or secure Kubernetes clusters, you will encounter it when defining namespace guardrails, migrating from PodSecurityPolicy, or troubleshooting pod rejections caused by unsafe security settings.

For further reading, check out our articles on digest ransomware trends and notable incidents and comparing the best security awareness training platforms.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.