The Architecture of Kubernetes Pod Security Policy and the Transition to Pod Security Standards

The landscape of container orchestration security is currently undergoing a fundamental architectural shift. Within the Kubernetes ecosystem, the mechanisms used to enforce security boundaries at the pod level have evolved from the highly granular, yet notoriously complex, Pod Security Policies (PSP) to the streamlined and standardized Pod Security Admission (PSA) framework. This evolution is not merely a change in syntax or API endpoints; it represents a significant reimagining of how cluster administrators manage workload isolation, privilege escalation, and the principle of least privilege. Understanding the mechanics of the deprecated PSP system is essential for any engineer managing legacy clusters, while mastery of the new Pod Security Standards (PSS) is mandatory for anyone architecting modern, secure cloud-native environments.

As containerization revolutionized application deployment, it introduced a new attack surface. Without rigorous security controls, containers can serve as entry points for malicious actors to move laterally through a cluster or escalate privileges to the host node. The history of Kubernetes security has been a continuous attempt to solve the "root-on-node" problem—ensuring that a compromise within a container does not lead to a total compromise of the underlying infrastructure. This article examines the technical intricacies of Pod Security Policies, the systemic failures that necessitated their removal, and the implementation details of the current replacement standards.

The Mechanics of Pod Security Policies

Pod Security Policies (PSP) functioned as a specialized admission controller within the Kubernetes API server. The primary purpose of a PSP was to define a set of security constraints that a pod must satisfy before the API server would allow the pod to be scheduled on a node. This enforcement occurred during the admission phase, acting as a gatekeeper that intercepted requests to create or update pods.

The operational logic of PSP relied on a complex set of rules that dictated the operational environment of a container. By defining these rules, administrators could mitigate several high-risk security vectors:

• Isolation of Containers: PSPs allowed for the enforcement of strict boundaries between pods. By restricting the ability of a container to interact with the host or other pods, administrators could prevent unauthorized communication and cross-tenant data leakage.
• Privilege Restriction: This involves the granular limitation of the capabilities and permissions available to a container. By defining exactly what a container is allowed to do, the attack surface is minimized, leaving an attacker with limited utility even if they successfully execute code within a container.
• Prevention of Privilege Escalation: One of the most critical functions of a PSP was to prevent an attacker from gaining unauthorized access to resources beyond their assigned role, specifically by controlling how processes can gain higher-level privileges.

To effectively implement PSP, several technical dimensions had to be addressed within the policy definition:

• Linux Kernel Capabilities: PSPs could specify exactly which Linux capabilities (such as CAP_NET_ADMIN or CAP_SYS_ADMIN) a container was permitted to request. This prevented containers from performing high-risk system calls that could compromise the kernel.
• Volume Management: Administrators used PSPs to control the types of volumes that could be mounted. This was vital to prevent pods from mounting sensitive host paths, such as /etc or /var/run/docker.sock, which could lead to host takeover.
• Host Namespace Access: A core security component was the restriction of access to host namespaces, specifically the PID, IPC, and Network namespaces. Allowing a pod to share the host's PID namespace, for instance, could allow a containerized process to see and potentially signal processes running on the host.
• Security Profiles: PSPs provided the framework to enforce the use of AppArmor or SELinux profiles, adding an additional layer of Mandatory Access Control (MAC) to the container runtime.

Structural Implementation and Enforcement Workflows

The enforcement of Pod Security Policies was not a global setting but a complex web of bindings and authorizations. For a PSP to have any effect on a workload, it had to be correctly associated with the entity attempting to create the pod.

The workflow for enforcing PSPs typically followed these steps:

1. Cluster Support Verification: Before deployment, administrators had to ensure the underlying Kubernetes distribution provided the necessary admission controller support for PSPs.
2. Policy Definition: The creation of the PSP object itself, defining the constraints for capabilities, volumes, and namespaces.
3. Policy Binding: This was a critical and often error-prone step. Administrators had to create a binding between the PSP and either a specific user, a group, or a service account. This determined which pods would be subject to which rules.
4. Continuous Auditing: Because security requirements evolve, administrators were required to regularly audit and review PSP usage to identify gaps and adjust policies as new vulnerabilities emerged.

The complexity of this binding model was a primary driver for the eventual deprecation of the feature. Because permissions were bound to the requesting user or the service account, the authorization model was often inconsistent with how other Kubernetes resources were managed.

Technical Deficiencies and the Path to Deprecation

Despite its importance, Pod Security Policies were officially deprecated in Kubernetes version 1.21 and completely removed in version 1.25. The decision to move away from PSP was driven by significant architectural flaws that made the system difficult to manage and prone to human error.

One of the most significant issues was the dual authorization model. In PSP, the policy was bound to either the user or the service account. This created a scenario where a user might have permission to create a pod, but the service account used by the pod's deployment might not have the corresponding PSP. This discrepancy often led to "failed closed" scenarios where legitimate workloads were blocked, or more dangerously, security gaps where overly permissive policies were applied to avoid operational friction.

The following table outlines the specific technical reasons for the deprecation of PSP:

The complexity of the API also meant that engineers often found it difficult to determine which PSP applied to a specific scenario. This ambiguity frequently resulted in unintentional configuration errors, where a developer might accidentally grant more privileges than intended, thereby compromising the security of the entire Kubernetes environment.

Pod Security Admission (PSA) and the New Standards

To resolve the chaos introduced by PSP, Kubernetes introduced Pod Security Admission (PSA). This is a built-in admission controller that enforces the Pod Security Standards (PSS), which provide a much more streamlined and predictable way to manage workload security.

The PSA framework replaces the complex, per-user binding system with a much simpler mechanism based on namespaces. Administrators can apply security levels to a namespace, and any pod created within that namespace must adhere to the specified standard.

Pod Security Standard Levels

The PSS defines three distinct levels of security. The implementation of these levels allows administrators to choose the appropriate level of restriction based on the sensitivity of the workloads running in a given namespace.

1. Privileged: This level is essentially an "allow-by-default" mechanism. It is designed for system-level pods that require high-level access to the host, such as networking plugins or storage drivers. It does not restrict most security-related characteristics.
2. Baseline: This level provides a middle ground. It is intended to prevent most known privilege escalation paths without being so restrictive that it breaks common applications. It disallows highly sensitive host namespace sharing and privileged containers.
3. Restricted: This is the most stringent level. It is designed for multi-tenant environments where maximum isolation is required. It includes strict requirements for running as a non-root user, prevents almost all host namespace access, and heavily restricts Linux capabilities and volume types.

Enforcement via the Admission Controller

The transition from PSP to PSA marks a shift from a "policy-based" approach to a "standard-based" approach. Under the PSA, the admission controller checks the pod specification against the chosen standard (Privileged, Baseline, or Restricted) applied to the namespace.

The following table compares the enforcement characteristics of the Baseline and Restricted standards as defined in the transition documentation:

The implementation of the Restricted policy specifically targets fields within the spec.securityContext and spec.containers[*].securityContext to ensure that pods do not attempt to escalate their privileges through common vectors. For example, the runAsNonRoot field must be explicitly set to true to satisfy the Restricted standard, ensuring that the container engine will fail to start a process if it attempts to run as the root user.

Migration Strategies for Cluster Administrators

Migrating from Pod Security Policies to Pod Security Admission is a critical task for any organization running Kubernetes v1.21 or newer. Because PSP was removed in v1.25, clusters must be migrated to PSA to ensure continued security enforcement and operational stability.

A successful migration requires a methodical approach to ensure that security is not compromised during the transition.

• Audit Existing PSPs: The first step is to inventory all existing PSPs and understand the actual constraints they are enforcing. Administrators must determine which level of the Pod Security Standards (Privileged, Baseline, or Restricted) most closely matches the intent of each current PSP.
• Map PSPs to PSS Levels: This is the most complex part of the migration. An administrator must map the granular rules of a PSP to the broader categories of the PSS. If a PSP was specifically restricting certain host paths, the administrator must ensure the corresponding namespace is set to the "Restricted" level in PSA to maintain that level of security.
• Namespace Labeling: Once the mapping is complete, administrators apply the security policy to the namespace using labels. For example, to enforce the Restricted standard in a namespace named production, the following command would be used:
  kubectl label --overwrite namespace production pod-security.kubernetes.io/enforce=restricted
• Utilize the Audit/Warn Modes: Before enforcing a new standard, administrators should use the audit or warn modes of the PSA. This allows them to see which pods would violate the policy without actually blocking their creation.
  kubectl label --overwrite namespace staging pod-security.kubernetes.io/warn=restricted
• Test and Refine: Using the information from the audit logs, administrators can refine their application configurations (e.g., adjusting securityContext settings) before moving to full enforcement.

Conclusion: The Future of Kubernetes Workload Security

The transition from Pod Security Policies to Pod Security Admission represents a significant maturation of the Kubernetes security model. While PSP provided a powerful, granular toolset, its inherent complexity and the resulting administrative burden created a "security through confusion" environment where errors were inevitable. The shift to Pod Security Standards acknowledges that for security to be effective in a highly dynamic, automated environment, it must be predictable, standardized, and easy to implement at scale.

The new PSA framework provides the necessary abstraction to allow developers to focus on application logic while providing administrators with a robust, high-level mechanism to enforce isolation and prevent privilege escalation. By leveraging the Baseline and Restricted standards, organizations can achieve a "defense in depth" posture that mitigates the most common container escape and privilege escalation techniques. As the industry moves toward even more automated and ephemeral infrastructure, the ability to apply standardized security policies via namespace labeling will remain a cornerstone of secure, multi-tenant Kubernetes operations.

Sources

1. Wiz.io: From Pod Security Policies to Pod Security Standards
2. Practical DevOps: Kubernetes Pod Security Policies
3. Armosec: Pod Security Standards Glossary
4. Kubernetes GitHub: PSP Replacement KEP