Pod Security Standards: The PSP Replacement You Still Haven't Set Up

PodSecurityPolicies were removed in Kubernetes 1.25. That was quite a while ago. And yet, right now, there are production clusters running with no workload security policy enforcement whatsoever — because teams removed PSPs when they had to, said "we'll replace them properly soon," and haven't yet.

This is that article that helps you finally do it properly.

---

😤 Why PSPs Got Removed (And Why That Was Actually Fine)

PodSecurityPolicies were genuinely confusing. The admission logic was poorly documented, they interacted with RBAC in non-obvious ways, and getting them wrong often meant pods stopped scheduling with cryptic error messages. They did important things. They were also a pain to work with.

Pod Security Standards (PSS) — enforced through the Pod Security Admission controller — replace them with something much cleaner. Three profiles. Clear semantics. Namespace-level enforcement. No RBAC entanglement.

---

🧠 The Three Profiles — Simple Version First

Imagine you're renting out units in a building. You have three lease types:

• Privileged — The tenant can do literally anything. Knock down walls, run experiments with the gas lines. No restrictions. This is for system-level infrastructure workloads that genuinely need it.
• Baseline — Normal tenant rules. No illegal modifications. But they can hang pictures and rearrange furniture. Prevents known privilege escalation while allowing most normal workloads.
• Restricted — Full building code compliance. Read-only surfaces, runs as non-root, no privilege escalation, locked down capabilities. The tightest possible standard for sensitive workloads.

flowchart LR Privileged["🔴 Privileged\n(System workloads)"] --> Baseline["🟡 Baseline\n(Most apps)"] --> Restricted["🟢 Restricted\n(Sensitive apps)"]

---

⚙️ How to Actually Enable It

Pod Security Admission is built into Kubernetes since 1.23 — no extra install needed. You enable it per namespace using labels.

# Enforce restricted profile in your production namespace
kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=latest \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/warn-version=latest \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/audit-version=latest

👉 The three modes — enforce, warn, audit — are independent. You can audit everything, warn on restricted violations, but only enforce baseline. This is how you roll it out gradually without breaking production at 9am on a Monday.

The rollout strategy that actually works:

# Phase 1: audit only — see what would fail, don't break anything
kubectl label namespace production \
  pod-security.kubernetes.io/audit=restricted

# Check the audit logs for violations
kubectl get events -n production --field-selector reason=FailedCreate

# Phase 2: add warnings — developers see warnings but pods still schedule
kubectl label namespace production \
  pod-security.kubernetes.io/warn=restricted

# Phase 3: once violations are fixed — enforce
kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted

---

🛡️ What "Restricted" Actually Requires

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  seccompProfile:
    type: RuntimeDefault     # or Localhost with a custom profile
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL

That's the spec your pods need to pass the restricted profile. If your workload sets runAsRoot: true or doesn't drop capabilities, it gets rejected at admission before it ever schedules.

---

⚠️ Common Mistakes

• Applying restricted to kube-system directly — System components often need elevated permissions. Label kube-system as privileged and enforce restricted everywhere else.
• Skipping the audit phase — Going straight to enforce without auditing first is how you find out at the worst possible moment that your log shipper DaemonSet runs as root.
• Thinking PSS replaces all of PSP's functionality — PSS doesn't cover network policies, volume restrictions, or fine-grained AppArmor profiles. For those, you still need a policy engine like Kyverno or OPA.

---

🔥 CloudChef Pro Tip

Use PSS as the floor, not the ceiling.

👉 PSS enforces the profile baseline. Kyverno or OPA handles everything else — specific image registries, required labels, resource limit enforcement. They work together, not as alternatives.

🔗 Continue Your CloudChef Journey

🔥 Related CloudChef Recipes

Loading related posts...

---

📚 References

• Kubernetes Pod Security Standards
• Pod Security Admission Documentation

---

🚀 Final Thoughts

PSP removal was a blessing in disguise. Pod Security Standards are cleaner, easier to reason about, and built into Kubernetes with zero extra setup. The only thing stopping you from enabling them right now is the same thing that stopped PSP adoption: taking the time to actually do it.

👉 Start with audit mode today. See what breaks. Fix it. Then enforce. It's not complicated — it just takes the decision to actually start.