Pod Security Standards & Pod Security Admission for the KCSA Exam: Privileged, Baseline, Restricted & Namespace Enforcement

Introduction

Ask any Kubernetes security engineer what the single most common cluster misconfiguration is, and you will hear the same answer: pods running with more privilege than they need. A container that runs as root, mounts the host filesystem, shares the host network namespace, or requests privileged: true is one exploited application away from a full node compromise. The KCSA exam treats this as core knowledge, and the mechanism Kubernetes ships to control it is Pod Security Admission (PSA) enforcing the Pod Security Standards (PSS).

This pairing replaced the deprecated and now-removed PodSecurityPolicy (PSP), and it shows up across two KCSA domains: it is a headline item in Kubernetes Security Fundamentals (22% of the exam) and it maps to the privilege escalation and malicious code execution branches of the Kubernetes Threat Model (16%). If you understand the three profiles, the three modes, and how namespace labels wire them together, you will comfortably answer every Pod Security question the exam throws at you — and, more importantly, you will know how to lock down a real cluster.

This guide walks the topic the way the KCSA frames it: what the standards actually are, what each profile blocks, how admission enforces them, and the operational gotchas that trip people up in production. If you want the surrounding context first, review Kubernetes Security Fundamentals and the Kubernetes Threat Model, then come back here to go deep on Pod Security.

Two Concepts, One System: Standards vs. Admission

The first thing to get straight — and a favorite exam distinction — is that Pod Security Standards and Pod Security Admission are two different things:

Term	What it is	Analogy
Pod Security Standards (PSS)	The policy definitions — three named profiles (`privileged`, `baseline`, `restricted`) describing which pod security settings are allowed	The rulebook
Pod Security Admission (PSA)	The enforcement mechanism — a built-in admission controller that checks pods against a chosen standard at a chosen mode	The referee applying the rulebook

The standards are just documentation-backed sets of rules. PSA is the code — a built-in validating admission controller, enabled by default since Kubernetes v1.25 (stable) — that actually evaluates pods against those rules when they are created or updated. You select which standard applies per namespace, using labels. Neither the standards nor the admission controller change a pod; PSA is purely a gate that allows or denies (or warns about) a pod based on its securityContext and spec.

The Three Profiles

Pod Security Standards define exactly three profiles, arranged from most permissive to most locked-down. Knowing what each one permits and blocks is the heart of the topic.

Privileged — Unrestricted

The privileged profile is wide open. It applies no restrictions at all and allows known privilege escalations. It exists for genuinely trusted, system-level, and infrastructure workloads — CNI plugins, storage drivers, log shippers, and other DaemonSets that legitimately need host access. If a namespace is set to privileged, PSA will admit any pod, including ones that request privileged: true containers, host namespaces, or hostPath mounts.

Baseline — Minimally Restrictive

The baseline profile blocks known privilege escalations while staying easy to adopt for typical applications. It is meant as a sensible floor that most existing workloads can meet without changes. Baseline prevents things like:

privileged: true containers
Sharing host namespaces (hostNetwork, hostPID, hostIPC)
hostPath volumes
Host ports (with narrow exceptions)
Adding dangerous Linux capabilities beyond a small allowed set (only NET_BIND_SERVICE may be added)
Unsafe /proc mounts, unsafe sysctls, and hostProcess Windows containers
AppArmor/SELinux/seccomp overrides that weaken the sandbox

Baseline does not require you to drop capabilities, run as non-root, or set a seccomp profile — it only stops the clearly dangerous settings.

Restricted — Heavily Restricted

The restricted profile follows current pod hardening best practices and is what you want for security-sensitive, multi-tenant, or internet-facing workloads. It is strict, and many off-the-shelf images will not run under it without adjustment. On top of everything baseline blocks, restricted requires pods to positively assert hardened settings:

runAsNonRoot: true (the container must not run as UID 0)
allowPrivilegeEscalation: false
Drop all capabilities (capabilities.drop: ["ALL"]); only NET_BIND_SERVICE may be re-added
A seccomp profile of RuntimeDefault or Localhost (not Unconfined)
Restricted volume types only (no hostPath; things like configMap, secret, emptyDir, persistentVolumeClaim, projected volumes are fine)

A useful mental model for the exam: baseline is a blocklist (“don’t do these dangerous things”), while restricted is closer to an allowlist (“you must explicitly prove you’re hardened”).

Profiles at a Glance

Control	Privileged	Baseline	Restricted
`privileged: true` container	Allowed	Blocked	Blocked
Host namespaces (net/PID/IPC)	Allowed	Blocked	Blocked
`hostPath` volumes	Allowed	Blocked	Blocked
Add capabilities beyond `NET_BIND_SERVICE`	Allowed	Blocked	Blocked
Must run as non-root	Not required	Not required	Required
`allowPrivilegeEscalation: false`	Not required	Not required	Required
Drop ALL capabilities	Not required	Not required	Required
seccomp `RuntimeDefault`/`Localhost`	Not required	Not required	Required

The Three Modes

Choosing a standard is only half the decision. PSA also lets you choose how the standard is applied, through three independent modes. This is the second half of the exam topic and just as important as the profiles.

Mode	Effect when a pod violates the standard
enforce	The pod is rejected. It never gets created.
audit	The pod is allowed, but a violation is recorded in the audit log.
warn	The pod is allowed, but a warning is returned to the user (e.g. shown by `kubectl`).

The three modes are not mutually exclusive — you can set all three on the same namespace, and each can point at a different profile. A widely recommended rollout pattern is to enforce a lenient level while audit and warn at a stricter level, so you can see what would break before you tighten enforcement:

enforce: baseline — actually block the worst offenders now
audit: restricted and warn: restricted — surface everything that isn’t yet restricted-clean, without breaking it

This “enforce loose, warn strict” approach is exactly how you migrate a live namespace toward restricted safely, and it is a common scenario-style KCSA question.

Important nuance: enforce is evaluated only at pod creation/update — it does not apply to pod templates in Deployments or other controllers, and it does not retroactively evict already-running pods. warn and audit, by contrast, do evaluate controller resources like Deployments, which is why you can catch a bad Deployment template with a warning even though enforce only acts on the pods it eventually spawns.

Wiring It Together: Namespace Labels

PSA is configured almost entirely through labels on the Namespace object. There is no separate policy CRD to install for the built-in controller — the label is the policy binding. The label schema is:

pod-security.kubernetes.io/<MODE>: <LEVEL>
pod-security.kubernetes.io/<MODE>-version: <VERSION>   # optional, pins the standard's version

A namespace that enforces restricted while warning and auditing at restricted looks like this:

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

The optional -version label pins the profile to a specific Kubernetes version’s definition (e.g. v1.31) instead of latest. Pinning matters because the standards evolve between releases; pinning prevents a cluster upgrade from silently tightening what your namespace enforces. latest is convenient but can surprise you on upgrade — a classic operational trade-off the exam may probe.

You can apply labels imperatively too, which is handy in the lab:

kubectl label namespace payments \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/warn=restricted --overwrite

If you set no labels at all, the cluster falls back to its Admission Configuration defaults (often privileged enforce in a vanilla cluster, or a hardened default if the platform team configured one). This cluster-wide default is set in the API server’s AdmissionConfiguration file for the PodSecurity plugin — worth knowing exists, even if you rarely touch it.

A Pod That Passes Restricted

To make the restricted requirements concrete, here is a pod spec that satisfies them. Notice how every hardening control from the table above is present:

apiVersion: v1
kind: Pod
metadata:
  name: hardened-app
  namespace: payments
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      image: myregistry.example.com/app:1.4.2
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: ["ALL"]
      ports:
        - containerPort: 8080

Remove any one of runAsNonRoot, allowPrivilegeEscalation: false, the drop: ["ALL"], or the seccomp profile, and PSA in enforce: restricted mode will reject the pod with a clear message naming the violated control. Try it in a lab namespace — the rejection text is genuinely helpful and tells you exactly which field to fix.

Why PodSecurityPolicy Is Gone

The KCSA exam expects you to know the history here. PodSecurityPolicy (PSP) was the original in-tree mechanism for this job. It was deprecated in v1.21 and removed entirely in v1.25. PSP was powerful but notoriously hard to use safely:

It was bound via RBAC in a confusing, order-dependent way — the wrong PSP could be selected when multiple applied, based on an opaque ordering.
It was mutating as well as validating, so it could silently change your pods, making behavior hard to predict.
Getting the authorization model right (who is allowed to use which policy) was a frequent source of lockouts and privilege bugs.

Pod Security Admission was designed to fix these problems by being deliberately simpler: a small, fixed set of well-documented profiles, purely validating (never mutating), and bound by namespace label instead of RBAC gymnastics. The trade-off is intentional — PSA is less flexible than PSP was. If you need finer-grained or custom rules (say, “images must come from our registry” or “every pod must carry a cost-center label”), PSA cannot express that, and you reach for a policy engine admission webhook instead. That connection to admission control is covered in Platform Security for the KCSA Exam.

PSA vs. Policy Engines

A recurring exam theme is knowing when built-in PSA is enough and when you need more. Built-in PSA gives you the three standard profiles and nothing else. When requirements go beyond “how privileged is this pod,” you layer a validating/mutating admission webhook — a general-purpose policy engine — on top.

Need	Right tool
Enforce privileged/baseline/restricted per namespace	Built-in Pod Security Admission
Custom rules (allowed registries, required labels, image signing, resource limits)	Policy engine admission webhook (e.g. OPA/Gatekeeper, Kyverno)
Mutate pods to add defaults (inject sidecars, set defaults)	Mutating admission webhook

The KCSA doesn’t require deep knowledge of any specific third-party engine, but it does expect you to know that PSA covers the standard profiles and that anything custom belongs in the broader admission-control layer. Don’t over-reach: if a question is about privileged/baseline/restricted, the answer is PSA.

Common Mistakes and Exam Traps

These are the misconceptions that cost people points — and cause real production incidents:

Confusing profiles with modes. restricted is a profile (what is allowed); enforce is a mode (what happens on violation). A question can mix and match them freely.
Assuming enforce evicts running pods. It does not. Changing a namespace to enforce: restricted does not kill pods already running that violate it — enforcement only gates new pods and updates. You must recreate workloads to apply it retroactively.
Forgetting enforce ignores controller templates. enforce acts on pods; warn/audit also evaluate Deployments/Jobs/etc. This is why a broken Deployment can be admitted while the pods it creates are rejected.
Thinking baseline requires non-root. It does not — only restricted requires runAsNonRoot. Baseline just blocks the dangerous stuff.
Overusing privileged namespaces. kube-system and infra namespaces legitimately need it; application namespaces almost never do. A privileged-labeled app namespace is a red flag.
Not pinning -version. Leaving the standard at latest means a cluster upgrade can tighten enforcement and break workloads unexpectedly.

How This Maps to the KCSA Threat Model

Pod Security is not an isolated topic — it is a direct mitigation for several branches of the Kubernetes Threat Model:

Privilege escalation: restricted’s allowPrivilegeEscalation: false, non-root requirement, and capability dropping directly close the most common escalation paths.
Malicious code execution / container breakout: blocking privileged, host namespaces, and hostPath removes the routes an attacker uses to reach the node from inside a pod.
Access to sensitive data: stopping hostPath mounts prevents a compromised pod from reading node-level secrets and credentials.

Pair Pod Security with RBAC, Network Policies, and Secrets hardening — the other pillars from Kubernetes Security Fundamentals — and you have defense in depth rather than a single brittle control. This layered thinking is exactly the mindset the KCSA rewards.

Practice This Hands-On

Reading the profiles is one thing; feeling the rejection messages and building the right securityContext from muscle memory is another. The most reliable way to lock this in is to create three namespaces (privileged, baseline, restricted), throw the same deliberately-bad pod at each, and watch what PSA does. Then fix the pod field by field until it passes restricted.

If you want that practice under realistic exam conditions — scenario questions that force you to distinguish profiles from modes, reason about label combinations, and pick PSA vs. a policy engine — the KCSA Certification-Ready Mock Exam Bundle is built exactly for that. It mirrors the real domain weightings, so Pod Security sits alongside the RBAC, network policy, and threat-model questions you’ll see on exam day, and every question comes with an explanation that reinforces why an answer is right. Use it after you’ve done the hands-on lab to confirm the concepts have actually stuck. For a broader plan, pair it with the KCSA study plan and time-boxed KCSA practice questions.

Frequently Asked Questions

What is the difference between Pod Security Standards and Pod Security Admission?

Pod Security Standards (PSS) are the policy definitions — three profiles named privileged, baseline, and restricted. Pod Security Admission (PSA) is the built-in admission controller that enforces one of those standards per namespace at a chosen mode. Standards are the rulebook; admission is the referee.

What are the three Pod Security Standard profiles?

privileged (unrestricted, for trusted system workloads), baseline (blocks known privilege escalations but easy to adopt), and restricted (enforces current hardening best practices such as non-root, dropped capabilities, and a seccomp profile).

What are the three Pod Security Admission modes?

enforce (reject violating pods), audit (allow but record a violation in the audit log), and warn (allow but return a user-facing warning). The three modes are independent and can each target a different profile in the same namespace.

Does enforce mode remove pods that are already running?

No. enforce only gates pod creation and updates. Pods already running that violate a newly applied standard keep running until they are recreated. You must roll or recreate the workloads to apply enforcement retroactively.

What replaced PodSecurityPolicy?

Pod Security Admission replaced PodSecurityPolicy (PSP). PSP was deprecated in Kubernetes v1.21 and removed in v1.25. PSA is simpler, purely validating (never mutating), and configured by namespace labels instead of RBAC bindings.

When should I use a policy engine instead of Pod Security Admission?

Use built-in PSA for the standard privileged/baseline/restricted profiles. Reach for a policy-engine admission webhook (such as OPA/Gatekeeper or Kyverno) when you need custom rules PSA can’t express — allowed registries, required labels, image-signing checks, or mutating defaults.

Does baseline require containers to run as non-root?

No. Only the restricted profile requires runAsNonRoot: true. The baseline profile blocks dangerous settings like privileged, host namespaces, and hostPath volumes, but does not require positive hardening like non-root or dropped capabilities.

Conclusion

Pod Security Standards and Pod Security Admission are one of the highest-leverage topics on the KCSA exam because they map so directly to real cluster security. Remember the shape: three profiles (privileged, baseline, restricted) describe what is allowed; three modes (enforce, audit, warn) describe what happens on violation; and namespace labels bind them together. Keep the profile-versus-mode distinction crisp, remember that enforce only gates new pods, know that PSA replaced the removed PodSecurityPolicy, and understand where built-in PSA stops and policy engines begin.

Get comfortable building a restricted-compliant securityContext by hand, practice the “enforce loose, warn strict” migration pattern, and you’ll answer every Pod Security question with confidence — and walk away able to actually harden a production cluster. From here, continue with Kubernetes Security Fundamentals for the RBAC and network-policy pillars, revisit the 4Cs of Cloud Native Security for the big picture, and check the full KCSA exam guide for 2026 to see how this topic fits the overall blueprint.