DevOps Dictionary

Kubernetes Pod Security Admission, often called PSA, is a built-in Kubernetes admission controller that checks Pod specifications against Kubernetes Pod Security Standards before the API server accepts them. It helps teams block or flag risky Pod settings, such as privileged containers, host namespace access, or running as root.

What Kubernetes Pod Security Admission does

Pod Security Admission applies security rules at the namespace level. When someone creates or updates a Pod, Kubernetes evaluates the Pod spec against a selected Pod Security Standard.

PSA can:

• Enforce a policy and reject Pods that do not meet it.
• Warn users when a Pod would violate a policy, while still allowing it.
• Audit violations by adding audit annotations to API server audit logs.

This makes PSA useful for platform teams that want baseline security controls without installing a third-party admission controller.

How it works

PSA uses labels on Kubernetes namespaces. These labels tell Kubernetes which Pod Security Standard to apply and what action to take.

The three built-in Pod Security Standards are:

• Privileged: Allows almost any Pod configuration. This is typically used only for trusted system workloads.
• Baseline: Blocks known privilege escalation paths while allowing common application patterns.
• Restricted: Applies stricter controls, such as requiring non-root execution and limiting Linux capabilities.

Example namespace labels:

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

With this configuration, Kubernetes rejects Pods in the payments namespace if they violate the restricted standard.

Common use cases

• Setting default security boundaries for application namespaces.
• Blocking privileged containers in tenant, staging, or production environments.
• Replacing PodSecurityPolicy, which was removed in Kubernetes 1.25.
• Rolling out stricter controls gradually by starting with warn and audit before using enforce.
• Standardizing cluster security across teams using namespace templates, GitOps, Terraform, or platform automation.

Key labels

PSA uses these namespace labels:

• pod-security.kubernetes.io/enforce: Rejects Pods that violate the selected standard.
• pod-security.kubernetes.io/audit: Records policy violations in audit logs.
• pod-security.kubernetes.io/warn: Shows warnings to users or CI/CD systems.

You can also pin a policy to a Kubernetes version:

pod-security.kubernetes.io/enforce-version: v1.30

Version pinning helps avoid unexpected behavior when upgrading Kubernetes. If you run production clusters, review PSA behavior as part of your upgrade plan. This fits well with practical Kubernetes upgrade planning, such as the process covered in Kubernetes upgrade tips for startups.

Benefits

• Built into Kubernetes: No extra controller is required for basic Pod security checks.
• Simple operating model: Policies are applied through namespace labels.
• Good default standards: The built-in levels cover many common container security risks.
• Gradual adoption: Teams can test with warn and audit before enforcing policies.
• Works with existing workflows: You can manage namespace labels through GitOps, Helm, Kustomize, or Terraform. For example, teams that manage Kubernetes objects as code can apply PSA labels using patterns similar to deploying Kubernetes resources with Terraform.

Tradeoffs and limitations

• Namespace-level control: PSA does not provide fine-grained per-workload policy logic.
• No mutation: It does not automatically fix Pod specs. It only allows, warns, audits, or rejects.
• Limited customization: You cannot define custom policy rules directly in PSA.
• No runtime protection: PSA checks admission-time configuration. It does not monitor container behavior after the Pod starts.
• Exceptions need care: Exemptions can be configured for users, namespaces, or runtime classes, but broad exemptions can weaken the policy.

If you need custom rules, such as requiring specific image registries, blocking unsafe annotations, or enforcing organization-specific labels, you may need tools like Kyverno, OPA Gatekeeper, or ValidatingAdmissionPolicy.

Simple real-world example

A platform team runs a shared Kubernetes cluster for several product teams. They label all application namespaces with baseline in enforce mode and restricted in warn mode.

This setup blocks clearly risky Pods, such as containers using privileged: true, while giving teams time to fix workloads that are not yet compatible with the stricter restricted standard.

After teams update their deployment manifests, the platform team changes production namespaces to enforce restricted.

PSA vs PodSecurityPolicy

Pod Security Admission replaced the older PodSecurityPolicy approach for built-in Kubernetes Pod security controls.

• PodSecurityPolicy was a Kubernetes API resource with more detailed controls, but it was complex to operate and was removed in Kubernetes 1.25.
• Pod Security Admission is simpler and uses predefined standards applied with namespace labels.

In practice, PSA is a good default for baseline Pod hardening. For custom policy requirements, pair it with a dedicated admission policy tool.