Skip to main content

Documentation Index

Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt

Use this file to discover all available pages before exploring further.

In this article, we explore Pod Security Admission (PSA) and Pod Security Standards as defined in Kubernetes Enhancement Proposal KEP-2579. PSA is designed to replace Pod Security Policies (PSP) with a solution that is safe to enable on new clusters, easy to use, and highly extensible. This approach meets several key requirements outlined in the proposal.
The image lists pod security requirements, including validation, safety, built-in controller, Windows support, API responsiveness, ease of use, and extensibility, related to KEP 2579 PSP Replacement.
The new implementation prioritizes simplicity and safety. Advanced or custom configurations can still be managed by third-party solutions such as KRAIL, Kyverno, or OPA Gatekeeper. PSA operates as an Admission Controller and is enabled by default in Kubernetes clusters. To verify its activation, run the following command to display the enabled admission plugins in the kube-apiserver: 
kubectl exec -n kube-system kube-apiserver-controlplane -it -- kube-apiserver -h | grep enable-admission-plugins
Since PSA is active by default, no extra steps are required to enroll it. Simply run the above command within the kube-apiserver pod and search for entries related to pod security to confirm its configuration. PSA is applied at the namespace level by using specific labels. For example, to enforce Pod Security Standards on a namespace named “payroll”, add the appropriate pod security settings to that namespace by specifying a mode and a security policy.
There are three built-in profiles provided by the Pod Security Standards:
  • Privileged: Offers nearly no restrictions, allowing extensive permissions and potential privilege escalation.
  • Baseline: Balances security and functionality by preventing unauthorized privilege escalation while supporting most containerized applications.
  • Restricted: Implements strict security measures based on pod hardening best practices, ensuring high security at the cost of potential compatibility challenges.
A mode determines the action taken when a policy violation occurs. The available modes are:
  • enforce: Rejects pod creation requests that do not comply with the specified policy.
  • audit: Allows pod creation but logs the policy violation in the audit logs.
  • warn: Permits pod creation and issues a warning to the user regarding the policy violation.
The image explains configuring PSA with modes (enforce, audit, warn) and profiles (Privileged, Baseline, Restricted), detailing actions on violations and policy descriptions.
For instance, if you label a namespace to “enforce” the restricted policy, any pod that fails to meet the strict criteria will be refused. Conversely, setting the mode to “warn” under the restricted profile will allow pod deployment but alert the user with a warning. The baseline profile is optimized for most containerized applications by preventing unauthorized elevated access. For further details on the restrictions applied by this profile, refer to the Kubernetes Pod Security Standards documentation.
The image shows a "Baseline Profile" for Kubernetes security, detailing policies and restrictions for host processes, namespaces, privileged containers, and more.
In contrast, the restricted profile applies the latest security best practices. Although this may lead to compatibility challenges, it ensures a robust security posture.
The image outlines Kubernetes pod security standards for a "Restricted Profile," detailing policies on volume types, privilege escalation, non-root user requirements, and capabilities.
In our example setup, we demonstrate different security configurations across namespaces:
NamespaceModeProfileDescription
payrollenforcerestrictedPods must strictly adhere to the restricted policy.
hrenforcebaselinePods are expected to follow baseline security practices.
devwarnrestrictedPods receive warnings if they do not comply with the restricted policy.
The commands to label the respective namespaces are as follows: 
kubectl label ns payroll pod-security.kubernetes.io/enforce=restricted
kubectl label ns hr pod-security.kubernetes.io/enforce=baseline
kubectl label ns dev pod-security.kubernetes.io/warn=restricted
This configuration ensures that pods within the “payroll” namespace are strictly enforced under the restricted policy, pods in the “hr” namespace adhere to baseline security practices, and pods in the “dev” namespace trigger warnings for violations under the restricted policy.
We encourage you to experiment with Pod Security Admission and Pod Security Standards to better understand how they enhance security in Kubernetes clusters. For additional information, visit the Kubernetes Documentation.

Watch Video