DevOpsInterviewPrep logo
DevSecOps & Supply Chain Security / 09
mediumNewRed HatGitLabPhonePe

PodSecurityPolicy was removed from Kubernetes. What replaced it, and how do you roll pod security out safely?

Naming the replacement is the floor of this question. What scores is the audit-then-warn-then-enforce sequence and an honest answer about the vendor chart you cannot fix.

Updated Sep 2026 · Grounded in researched DevOps, SRE and platform engineering interview loops, written to a senior-engineer editorial bar, and never padded to hit a word count.

TL;DR: Pod Security Admission with its Baseline and Restricted profiles is the built-in floor, extended by Kyverno or Gatekeeper for rules that need context. Roll out per namespace as audit, then warn, then enforce, using actual violations to plan migrations before enforcement blocks releases.

How to approach it

Give the history one line (PSP removed in v1.25 for being confusing and non-portable), then structure around the two-layer replacement and the rollout order. The rollout order is where operational judgement shows, so spend your time there.

A strong answer

Layer one is Pod Security Admission, stable in v1.25 after earlier alpha/beta availability. Three profiles: privileged, no restrictions; baseline, blocking known privilege escalations such as privileged containers, host namespaces and hostPath; restricted, the hardened set requiring run-as-non-root, dropped capabilities, allowPrivilegeEscalation: false and a seccomp profile. Profiles attach per namespace through labels, and usefully three modes coexist, so a namespace can enforce baseline today while auditing restricted in parallel:

labels:
  pod-security.kubernetes.io/enforce: baseline
  pod-security.kubernetes.io/warn: restricted
  pod-security.kubernetes.io/audit: restricted
  pod-security.kubernetes.io/enforce-version: v1.36
  pod-security.kubernetes.io/warn-version: v1.36
  pod-security.kubernetes.io/audit-version: v1.36

Pin the version to a release supported by your cluster; v1.36 is an example to review during upgrades. PSA version labels.

Layer two covers what PSA deliberately cannot express. PSA is context-free: it sees a pod spec and nothing else. The moment you want registry allowlists, image tag rules, signature verification or per-workload exceptions, use an additional admission control. ValidatingAdmissionPolicy can enforce object-local checks such as registry, tag or required labels; signature verification needs a suitable external verifier. Kyverno writes as ordinary Kubernetes YAML and can mutate as well as validate; Gatekeeper uses Rego constraints and fits organisations already standardising on OPA. A sane split: PSA as the non-negotiable security floor on every namespace, engine policies for supply-chain and organisational rules above it.

Rollout order decides whether any of this survives contact with a release calendar. Label namespaces audit-only and let violations accumulate into a dashboard for two weeks. Some violations need only a securityContext change; others require image or application changes that must be tested. Move to warn mode so engineers see failures at deploy time while releases continue uninterrupted. Enforce last, namespace by namespace, starting with newly created namespaces where no legacy exists. Vendor Helm charts you cannot modify get quarantined in their own namespace at baseline, with a recorded exception naming an owner and an expiry date. Exceptions without expiry dates are permanent exceptions wearing a temporary costume.

Prefer fixing templates over mutating pods at admission. Mutation can create drift, but idempotent mutation and correctly configured diff/reconciliation behavior can coexist with GitOps. Review ownership and avoid two controllers rewriting the same field.

What interviewers probe next

"What can PSA not express?" Custom image registry/tag restrictions, signatures, required labels and cross-resource rules. Some are object-local checks; others require external context or a verifier. That gap is precisely why layer two exists rather than being optional polish.

"Restricted mode breaks a legacy app that must run as root." Fixing the image is the real answer: non-root user, writable volume for whatever it wrote to root. Short term, isolate it in its own baseline namespace behind an expiring waiver and a tracking ticket with the owning team's name on it.

"Does this replace NetworkPolicy?" No, orthogonal planes: pod security constrains what a workload may do on the node, NetworkPolicy constrains what it may reach on the network. A hardened pod that can reach everything is half protected.

Common mistakes

Enforcing Restricted across namespaces before checking their actual violations and testing the required changes.

Relying on mutation until manifests in git stop matching running pods, then spending months debugging drift nobody can explain.

Treating PSA and Kyverno as competing choices instead of floor and extension.

That one was free, and so are 10 answers per topic without an account. Signing in doubles that to 20, keeps your bookmarks, and tracks which topics you keep getting wrong.one Google click · no card · nothing to cancel
HOW DID IT GO?
0
UP NEXT ON YOUR JOURNEY
DISCUSSION · 0

Nothing here yet. Say how you would answer it.