Pod Security Admission: Kubernetes' Built-in Guardrails
Think of Pod Security Admission (PSA) as a bouncer for your namespaces, enforcing security rules before pods can run. It applies security standards (Privileged, Baseline, Restricted) via simple labels.
Why it exists
Kubernetes needed a simpler, more maintainable way to enforce basic pod security than the deprecated PodSecurityPolicy (PSP). PSP was powerful but overly complex and easy to misconfigure, often leading to either insecure clusters or broken workloads. PSA provides a standardized, out-of-the-box solution that is easier to reason about.
The mental model
Think of PSA as a set of security "dress codes" for your Kubernetes namespaces. Each namespace can have a different code: Privileged (no rules), Baseline (business casual, prevents obvious risks), or Restricted (formal attire, very strict). The PSA admission controller acts as the bouncer, checking every new pod against its namespace's dress code before it's allowed in.
How it works
PSA is a built-in admission controller that's enabled by default in modern Kubernetes clusters. You configure it by applying labels to namespaces. For example, pod-security.kubernetes.io/enforce: baseline tells the controller to reject any pod in that namespace that doesn't meet the Baseline standard. You can also set modes for warn (log a warning but allow the pod) and audit (log the violation for later review). The controller intercepts pod creation requests and validates them against the policy defined by the namespace label.
When to use it
Use PSA to establish a baseline security posture across your cluster. It's ideal for preventing common misconfigurations and privilege escalation vectors in application namespaces. Applying the Baseline policy to all non-system namespaces is a standard best practice. Use the Restricted policy for namespaces running untrusted or multi-tenant workloads that require maximum hardening.
When not to use it
The Privileged level effectively disables PSA, and should only be used for highly trusted, system-level components that require deep host access, such as CNI plugins or storage drivers in the kube-system namespace. Avoid PSA if you need fine-grained policy control beyond the three predefined levels; for that, a third-party admission controller like Kyverno or OPA Gatekeeper is a better fit.
One canonical example
To protect a namespace named app-staging from running insecure pods, you apply the Baseline policy. The command is: kubectl label --overwrite ns app-staging pod-security.kubernetes.io/enforce=baseline. Now, if a developer tries to deploy a pod with hostNetwork: true in that namespace, the API server will reject it with an error message explaining the violation.
Interview question
Under which circumstance would an administrator likely choose a third-party admission controller over Pod Security Admission (PSA)?
- a.To implement security policies that require dynamic evaluation based on external data sources.
- b.To manage security policies from a central cluster-wide configuration rather than per-namespace labels.
- c.To enforce security policies on non-pod resources, such as Deployments or Services.
- d.When the built-in Privileged, Baseline, or Restricted policies do not provide the necessary level of specific, granular control.Correct
Why? this is the answer
The card explicitly states that third-party admission controllers are preferred when 'fine-grained policy control beyond the three predefined levels' is required, which aligns with needing more specific, granular control. While third-party tools can manage other resources or offer central configuration, the card highlights policy granularity as the key differentiator from PSA.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
- #kubernetes
- #security
- #admission-controller
- #devops
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles