What Is Pod Security Standards? Security Definition

Imagine you are renting out rooms in a large apartment building to different tenants. Each tenant gets their own room (a pod), but you need to make sure they don't damage the building, spy on other tenants, or break into the central boiler room. Pod Security Standards are the rules you set for each tenant.

The least restrictive rule, called Privileged, lets the tenant do almost anything, like drilling holes in the walls or installing their own locks, which is useful for maintenance workers but risky for normal tenants. The middle rule, called Baseline, says no drilling, no picking locks, and no touching the electrical panel, but they can use the common areas normally. The most restrictive rule, called Restricted, says the tenant cannot even run as the building manager (root) inside their room, cannot see the hallway cameras, and must use a special door that cannot be opened from the outside.

In Kubernetes, these standards are applied to pods through admission controllers, which check every pod against the rules before it is allowed to run. The cluster administrator chooses which standard to apply to different namespaces, just like a landlord decides which rules apply to which floor of the building. This way, pods that need full access for monitoring or networking can run under Privileged, while regular application pods must follow Baseline or Restricted to keep the cluster safe from attacks like container breakouts or privilege escalation.

Pod Security Standards (PSS) were introduced in Kubernetes version 1.21 as a replacement for the deprecated Pod Security Policies (PSP). They are defined in the Kubernetes documentation as three distinct policy levels: Privileged, Baseline, and Restricted.

Each level controls a set of security fields in the pod's security context, including but not limited to: the ability to run as root, the usage of Linux capabilities (like CAP_SYS_ADMIN), the ability to mount host paths, the ability to use host networking, and the ability to run privileged containers. The Privileged level imposes no restrictions; it allows all security context settings and is intended for system components that require deep access to the host node. The Baseline level prohibits the most obvious and dangerous privileges while still allowing typical application deployments.

It restricts privileged containers, hostPID, hostIPC, hostNetwork, hostPath volumes, and the addition of dangerous Linux capabilities such as CAP_SYS_ADMIN, CAP_NET_ADMIN, and CAP_SYS_PTRACE. The Restricted level goes further by enforcing best practices for pod security. It requires that containers run as non-root, sets the seccomp profile to RuntimeDefault or Localhost, drops all default capabilities and only adds those explicitly needed, and prevents privilege escalation through the allowPrivilegeEscalation field set to false.

Implementation in a real IT environment involves using admission controllers, specifically the PodSecurity admission controller (built into kube-apiserver since 1.23). Administrators can enable this controller by adding it to the --enable-admission-plugins flag or by using a validating webhook.

Policies are applied at the namespace level using labels. For example, a namespace can be labeled with pod-security.kubernetes.io/enforce: restricted to automatically reject any pod that does not meet the Restricted standard.

Audit and warn modes are also available, allowing administrators to log violations or display warnings without blocking deployments, which is useful for migration from older policies. The standards align with the Pod Security Context API, which defines fields like runAsUser, runAsGroup, fsGroup, seLinuxOptions, seccompProfile, and capDrop in the pod specification. When a pod is submitted to the API server, the PodSecurity controller evaluates the pod's specification against the baseline or restricted requirements.

If the pod violates a mandatory field, such as attempting to run as root in a namespace enforcing Restricted, the API server rejects the request and returns an error. This mechanism ensures that security policies are enforced consistently across the cluster without manual review of every pod definition.

Pod Security Standards matter because they are one of the most fundamental controls for securing a Kubernetes cluster. Containers share the host kernel, so a compromised container can potentially break out and gain access to the host node, other containers, or sensitive data. Without proper restrictions, a malicious or misconfigured container can run as root, mount sensitive host paths like /var/lib/kubelet or /proc, and install kernel modules.

Pod Security Standards provide a standardized, easy-to-implement framework that prevents these dangerous configurations. In real IT work, especially for organizations subject to compliance requirements like PCI DSS, HIPAA, or SOC 2, enforcing least privilege on containers is not optional. For example, a financial services company running payment processing on Kubernetes must ensure that no container runs as root and that sensitive host resources are not exposed.

Using Restricted-level standards across production namespaces satisfies many compliance controls. Additionally, Pod Security Standards simplify security management compared to the legacy Pod Security Policies, which were complex to write and maintain. With labels on namespaces, administrators can roll out policies incrementally, starting with warn mode to identify violations without breaking running applications, then switching to enforce mode once teams have updated their pod definitions.

This reduces friction between security teams and developers. Furthermore, Pod Security Standards integrate with existing Kubernetes tooling like kubectl, CI/CD pipelines, and GitOps workflows. Developers can test their pods locally against the standard using tools like kyverno or the kube-score linter.

For cluster operators, the standards reduce the attack surface significantly. Common attacks that Pod Security Standards mitigate include container breakout via privileged containers, resource exhaustion via host resource access, and credential theft via hostPath volume mounts. In summary, this concept matters because it directly translates security best practices into enforceable policies that protect the entire cluster infrastructure.

Exam questions about Pod Security Standards typically fall into three categories: configuration, troubleshooting, and architecture. In configuration questions, the candidate is asked to apply a specific Pod Security Standard to a namespace. For example: You have a namespace called finance that must only allow pods meeting the Restricted standard.

How would you label the namespace to enforce this? The correct answer involves setting the label pod-security.kubernetes.io/enforce: restricted on the namespace. A variation asks the candidate to create a pod that complies with the Baseline standard, specifying the correct securityContext fields such as runAsNonRoot: true or dropping CAP_SYS_ADMIN.

Troubleshooting questions present a pod that is in a pending state with an error about security context. The candidate must examine the pod events using kubectl describe pod, identify that the pod violates the namespace's Pod Security Standard, and then either modify the pod spec to comply or change the namespace label if appropriate. For instance, a pod might be failing because it uses hostNetwork: true in a namespace with Baseline enforcement, which prohibits hostNetwork.

The candidate would need to remove hostNetwork or move the pod to a Privileged namespace. Architecture questions ask about designing a secure cluster with multiple tenants. For example: Your organization has three teams: infrastructure (needs privileged access), web-app (standard), and batch-processing (high security).

Which Pod Security Standard would you apply to each namespace and why? The candidate must justify the choice by referencing the specific restrictions each level allows. Another common type is the migration question: Your cluster currently uses PodSecurityPolicies and you need to migrate to Pod Security Standards.

Describe the steps you would take, including the use of audit and warn modes. The correct answer includes labeling namespaces with warn mode first, checking logs, fixing violations, then switching to enforce mode. Performance-based tasks in the CKS exam may require the candidate to enable the PodSecurity admission controller on a cluster where it is not currently active.

This involves modifying the kube-apiserver configuration to add --enable-admission-plugins=PodSecurity and restarting the API server. Finally, questions may test the knowledge of the specific fields restricted by each level, such as that Restricted requires seccompProfile.type: RuntimeDefault and the dropping of ALL capabilities.

Candidates must memorize these details because the exam does not provide documentation.

Pod Security Standards are a critical control for anyone managing a Kubernetes cluster, especially in production environments. To configure them effectively, start by understanding your cluster's architecture. You should have a clear map of all namespaces and the workloads they run.

The first practical step is to enable the PodSecurity admission controller on your API server. If you manage your own control plane, edit the kube-apiserver manifest (often in /etc/kubernetes/manifests/) and add --enable-admission-plugins=NodeRestriction,PodSecurity to the command line. If you use a managed Kubernetes service like EKS, GKE, or AKS, the PodSecurity controller is already enabled by default or can be enabled through a feature gate.

Once enabled, you can apply namespace labels. Many organizations use a default namespace called default, but it is best practice to leave it unlabeled or label it with Baseline. For system namespaces like kube-system, you should apply Privileged because many system components require host access.

For user namespaces, choose Baseline for general workloads and Restricted for sensitive data. A common mistake is to label all namespaces with Restricted immediately, which breaks many applications that rely on running as root or using host resources. Instead, adopt a gradual approach: create a new namespace called production-secure with Restricted, then migrate only those applications that can comply.

For existing namespaces, use the warn mode first. For example, run kubectl label namespace production pod-security.kubernetes.io/warn=restricted. Then deploy your application and check the warnings.

In practice, you will find that many container images from public registries run as root by default. These images will fail under Restricted unless you override the security context in the pod spec. To fix this, you can add a security context at the container level: securityContext: { runAsNonRoot: true, runAsUser: 1000, allowPrivilegeEscalation: false, capabilities: { drop: [ALL] }, seccompProfile: { type: RuntimeDefault } }.

For the Baseline level, you mostly need to ensure that your pod does not use hostNetwork, hostPID, hostIPC, or hostPath volumes. Additionally, you must set the security context to drop the most dangerous capabilities. The default container runtime may add capabilities like NET_RAW or CHOWN; Baseline requires you to drop capabilities that allow system-level operations.

In a real environment, you can test compliance using tools like kubectl dry-run or by creating a simple pod with the --dry-run=server flag to see if the API server accepts it. Another practical tip: use the Pod Security Standards in combination with network policies and resource quotas for defense in depth. Even the Restricted standard does not prevent network-based attacks, so combining it with network policies for zero-trust networking is recommended.

If a container is compromised despite the Restricted standard, the attacker still cannot elevate privileges or access the host, limiting the blast radius. Finally, remember that Pod Security Standards are a starting point, not an end state. For advanced compliance, consider using OPA Gatekeeper or Kyverno to enforce custom policies beyond the three levels.

But for the CKS exam and most production clusters, mastering Pod Security Standards is sufficient.