Pod Security Admission - The PSP Replacement That Actually Works

Pod Security Policies were a clusterfuck. If you've ever spent 3 hours debugging why your pod wouldn't start because of some obscure RBAC binding you forgot about, you know what I'm talking about. PSA fixes that mess by ditching the complex policy-to-pod mapping nightmare that made PSPs impossible to debug.

PSA has been enabled by default since Kubernetes 1.23, but it starts in "privileged" mode globally - meaning it doesn't actually enforce anything until you configure namespace labels. This is actually smart because otherwise every cluster upgrade would break half your workloads.

Why Pod Security Policies Had to Die

PSPs got the axe in Kubernetes 1.21 and were completely removed in 1.25. Good riddance. Here's why they sucked:

• RBAC hell - You had to create ClusterRoles, RoleBindings, and ServiceAccounts just to figure out which policy applied to your pod. When it broke, good luck debugging that maze. I spent an entire Friday tracing through RBAC bindings trying to figure out why our monitoring pods stopped working after someone "cleaned up" some old ServiceAccounts.
• Policy selection mystery - Multiple PSPs could match your pod, and Kubernetes picked one using logic that nobody could predict. I've seen production outages caused by the "wrong" PSP getting selected after an innocent namespace cleanup.
• Cryptic errors - Error messages like unable to validate against any pod security policy told you absolutely nothing about what was actually wrong. You'd spend hours trying to figure out if it was RBAC, the policy itself, or some other random thing.
• No testing - You couldn't test policies without potentially breaking production. Every PSP change was a "hope and pray" moment, usually followed by "oh shit, that broke the logging daemonset."

The day PSPs stopped working in 1.25 staging went down for 3 hours because someone missed migrating the monitoring namespace. That's when I learned PSA the hard way.

How PSA Actually Works

PSA is a validating admission controller built into the Kubernetes API server. Unlike PSPs that required RBAC gymnastics, PSA uses simple namespace labels to define what's allowed. That's it. No ClusterRoles, no bindings, just labels.

When you try to create a pod, PSA checks it against the namespace's security profile before the pod even gets to the scheduler. If your pod violates the policy, you get an error immediately instead of watching it fail mysteriously later.

The key difference: PSA doesn't validate existing pods. Your old shit keeps running even if it violates the new policy. This saved my ass during our migration - we could enable PSA gradually without taking down production workloads.

The Three Security Profiles

PSA gives you three security levels. Pick your poison:

Privileged - Anything goes. Your containers can be root, mount the host filesystem, access the host network - basically do whatever the fuck they want. Use this for system pods (kube-proxy, CNI drivers) and when you absolutely need privileged access. Most legacy apps end up here because nobody wants to fix their shit.

Baseline - Blocks the obviously dangerous stuff like privileged containers and host networking, but still allows root users. This is where most production workloads live because developers haven't figured out how to run their apps as non-root yet. It's the "good enough" security level.

Restricted - The paranoid security level. Forces non-root users, read-only root filesystems, drops all Linux capabilities. Your app probably won't work with this unless it was designed with security in mind from day one. Great for new cloud-native apps, nightmare for legacy stuff.

Why PSA Actually Works

Here's what makes PSA better than the PSP shitshow:

• Namespace labels are explicit - You can kubectl get namespace -o yaml and immediately see what security policy applies. No more guessing which of your 47 PSPs is actually being used.
• Built into the API server - No more webhook timeouts taking down your deployments. PSAs runs inside kube-apiserver, so it's as reliable as the rest of Kubernetes.
• Three enforcement modes - enforce blocks stuff, audit logs violations, warn shows warnings to users. You can enable audit mode first to see what would break before you enforce anything.
• Better error messages - Instead of cryptic PSP errors, you get messages like violates PodSecurity "restricted:latest": securityContext.runAsNonRoot != true. Still not great, but way better than before.

The downside: PSA is namespace-level only. You can't have dev and prod workloads in the same namespace with different security requirements anymore. But honestly, if you were doing that with PSPs, you were probably doing it wrong anyway.

If you want to dig deeper into this stuff:

• Pod Security Standards specification - Detailed breakdown of what each security level blocks
• Kubernetes security best practices - Overall security guidance for Kubernetes clusters
• Admission controller architecture - How PSA fits into the Kubernetes request flow
• Security context best practices - How to configure pods to work with PSA
• Namespace organization patterns - Structuring your cluster for PSA
• Kubernetes RBAC guide - Understanding permissions and security contexts
• Container security fundamentals - Why these restrictions matter for security

PSA is a validating admission controller built into the Kubernetes API server. Unlike webhook-based admission controllers that can timeout and fuck up your deployments, PSA runs inside kube-apiserver itself, so it's as reliable as the rest of your control plane.

The Admission Process (When Your Pod Gets Judged)

When you kubectl apply a pod, here's what happens:

1. API server gets your request - Usually from kubectl, but could be Helm, GitOps, or whatever
2. Auth check - Are you allowed to create pods in this namespace? Basic RBAC stuff.
3. Mutating admission - Other controllers might add sidecar containers, inject secrets, whatever
4. PSA validation - This is where PSA looks at your pod and decides if it meets the namespace security policy
5. Rejection or acceptance - If PSA doesn't like your pod, you get an error and nothing gets created. If it's cool, your pod gets stored in etcd.

The key thing: PSA checks your pod after mutations but before it gets stored. So if another admission controller adds a privileged sidecar, PSA will catch that and block the whole thing.

Namespace Labels: The New Way to Control Security

Instead of the PSP RBAC nightmare, PSA uses simple namespace labels. That's it. Just labels on your namespace:

## What I actually use in prod (pin the version or K8s updates will screw you)
apiVersion: v1
kind: Namespace
metadata:
  name: production-workloads
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: v1.29  # ALWAYS pin this
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: v1.29
    pod-security.kubernetes.io/warn: baseline
    pod-security.kubernetes.io/warn-version: v1.29

Pro tip: Always pin the version (v1.29) or Kubernetes upgrades will change your security policies without warning. I learned this the hard way when a cluster upgrade from 1.28 to 1.29 started blocking pods that worked fine before.

The three modes save your ass during rollout:

• enforce - Blocks violating pods (use this in prod once you're sure)
• audit - Logs violations to the audit log (great for seeing what would break)
• warn - Shows warnings to users but allows the pod (perfect for dev environments)

You can see which policy applies with kubectl get namespace -o yaml - no more guessing like with PSPs.

Cloud Provider Reality Check

Amazon EKS - Works fine, PSA enabled by default in privileged mode. Makes sense since AWS needs their system pods to do whatever they want. EKS 1.23+ handles this properly. No surprises, no weird edge cases, just works.

Google GKE - Standard clusters work normally. Autopilot is different though - forces baseline security and you can't override it to privileged for user workloads. Great until your legacy app needs root, then you're fucked and have to refactor everything or switch to Standard.

Azure AKS - This is where it gets annoying. AKS has PSA AND Azure Policy for Kubernetes, and they can fight each other. You'll get confusing errors about which policy is blocking your pod. Microsoft's typical "let's add another layer of complexity" approach. Pick one system, not both, or you'll spend your weekend debugging policy conflicts.

Performance: PSA Doesn't Slow You Down

PSA is fast because it's built into kube-apiserver, not some external webhook that might be slow or unavailable:

• Sub-millisecond validation - PSA policy checks are simple comparisons, not complex logic
• No network calls - Unlike webhook admission controllers that can timeout and break your deployments
• Scales with your cluster - More API server replicas = more PSA capacity
• Cached policies - PSA caches namespace policies in memory, so it doesn't re-read labels every time

In practice, PSA adds less than 1ms to pod creation. You won't notice it unless you're creating thousands of pods per second, and if you are, PSA performance is the least of your problems.

What PSA Actually Checks

PSA examines your pod's security context and compares it against the namespace policy. Here's what it looks for:

• runAsUser/runAsGroup - Restricted mode requires non-root users (UID > 0)
• allowPrivilegeEscalation - Can your container gain more privileges after starting?
• capabilities - Which Linux capabilities your container gets (restricted mode drops all of them)
• volumes - Restricted mode blocks host path volumes and most others
• hostNetwork/hostPID/hostIPC - Baseline and restricted modes block host namespace access

Common gotcha: If your pod doesn't specify a security context, PSA uses the defaults. For restricted mode, you must explicitly set runAsNonRoot: true and runAsUser: 1000 (or any UID > 0). Forgetting this will get you Pod violates PodSecurity \"restricted\": securityContext.runAsNonRoot != true.

Debugging and Monitoring

PSA is way better than PSPs for debugging, but you still need to know where to look:

• kubectl describe pod shows PSA rejection reasons in the events
• Audit mode logs violations to the Kubernetes audit log without blocking anything
• Warning mode shows warnings to users: kubectl apply will show PSA warnings in the output
• Prometheus metrics - PSA exposes admission controller metrics if you have monitoring set up

The error messages are actually readable now, unlike PSP's cryptic bullshit. You'll get messages like violates PodSecurity \"restricted:latest\": allowPrivilegeEscalation != false which actually tells you what's wrong.

The only docs you actually need:

• Official PSA docs (if you like reading)
• Security context examples (when you're debugging violations)
• PSA troubleshooting guide (for when everything's broken)