Implementing Pod Security Admission Controller

Overview

Pod Security Admission (PSA) is a built-in Kubernetes admission controller (stable since v1.25) that enforces Pod Security Standards at the namespace level. It replaces the deprecated PodSecurityPolicy (PSP) and provides three security profiles: Privileged, Baseline, and Restricted, with three enforcement modes: enforce, audit, and warn.

When to Use

• Wiring PSA up on a cluster for the first time
• Setting cluster-wide default enforcement via AdmissionConfiguration
• Exempting system namespaces, service accounts, or runtime classes from enforcement
• Debugging why a pod was rejected, or why enforcement is silently not firing
• Staging a safe rollout: warn and audit first, enforce once violations reach zero
• Pulling PSA violations out of the kube-apiserver audit log

Not this skill: deciding which profile a workload should run under, or what securityContext changes Restricted demands. Use implementing-kubernetes-pod-security-standards.

Prerequisites

• Kubernetes v1.25+ (PSA is stable/GA)
• kubectl with cluster-admin access
• No dependency on external tools - PSA is built into kube-apiserver

Pod Security Standards

Privileged Profile

• Unrestricted - No restrictions applied
• Use case: System-level pods (kube-system, monitoring)

Baseline Profile

• Minimally restrictive - Prevents known privilege escalation
• Blocks: privileged containers, hostPID, hostIPC, hostNetwork, hostPorts, certain volume types, adding capabilities beyond runtime defaults

Restricted Profile

• Heavily restricted - Follows security best practices
• Requires: non-root, drop ALL capabilities, seccomp RuntimeDefault, read-only root filesystem considerations
• Blocks: Everything in Baseline plus running as root, privilege escalation, non-approved volume types

Enforcement Modes

Implementation

Apply to Namespace via Labels

# Restricted enforcement with audit and warn
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: v1.28
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: v1.28
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: v1.28

# Baseline enforcement for staging
apiVersion: v1
kind: Namespace
metadata:
  name: staging
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: v1.28
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: v1.28
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: v1.28

# Privileged for system namespaces
apiVersion: v1
kind: Namespace
metadata:
  name: kube-system
  labels:
    pod-security.kubernetes.io/enforce: privileged

Apply Labels with kubectl

# Set restricted enforcement
kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=v1.28 \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

# Set baseline enforcement
kubectl label namespace staging \
  pod-security.kubernetes.io/enforce=baseline \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

# Check current labels
kubectl get namespace production -o jsonpath='{.metadata.labels}' | jq .

Dry-Run Testing

# Test what would happen with restricted policy on a namespace
kubectl label --dry-run=server --overwrite namespace staging \
  pod-security.kubernetes.io/enforce=restricted

# Output shows existing pods that would violate the policy
# Warning: existing pods in namespace "staging" violate the new PodSecurity enforce level "restricted:latest"

Cluster-Wide Defaults (AdmissionConfiguration)

# /etc/kubernetes/psa-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: PodSecurity
    configuration:
      apiVersion: pod-security.admission.config.k8s.io/v1

…