Pod Security Standards: restricted
Demonstrate that all applicable namespaces enforce the Kubernetes Pod Security Standards 'restricted' profile, preventing deployment of pods with insecure configurations that could enable privilege escalation or container escape.
Description
What this control does
Pod Security Standards (PSS) 'restricted' policy is the most stringent profile defined by Kubernetes for hardening pod specifications. It enforces a comprehensive set of security restrictions including prohibiting privileged containers, host namespace sharing, privileged escalation, non-root user enforcement, restricted volume types, and limited capabilities. Implementing the 'restricted' profile minimizes the attack surface of containerized workloads by denying access to host resources and enforcing defense-in-depth principles at the pod level. This control is critical for multi-tenant clusters and environments processing sensitive data where container escape or lateral movement must be prevented.
Control objective
What auditing this proves
Demonstrate that all applicable namespaces enforce the Kubernetes Pod Security Standards 'restricted' profile, preventing deployment of pods with insecure configurations that could enable privilege escalation or container escape.
Associated risks
Risks this control addresses
- Privileged containers gaining root-level access to the underlying Kubernetes node and compromising the entire cluster
- Attackers exploiting host namespace sharing (PID, IPC, network) to observe or manipulate processes outside the container boundary
- Container escape attacks leveraging insecure volume mounts (e.g., hostPath) to access sensitive node file systems or credentials
- Privilege escalation within containers due to allowPrivilegeEscalation flag enabling setuid binaries or capability abuse
- Lateral movement across namespaces or nodes via unrestricted capabilities (CAP_SYS_ADMIN, CAP_NET_RAW) or host network access
- Malicious workloads running as root user subverting file permissions, security contexts, or log integrity within containers
- Supply chain compromises deploying backdoored images with privileged configurations bypassing runtime security controls
Testing procedure
How an auditor verifies this control
- Obtain a complete inventory of all Kubernetes namespaces in scope, excluding system namespaces (kube-system, kube-public) unless explicitly required by policy.
- Review the cluster-wide Pod Security Admission configuration by examining the AdmissionConfiguration resource or kube-apiserver flags to identify the default enforcement mode.
- For each in-scope namespace, extract the pod security labels (pod-security.kubernetes.io/enforce, pod-security.kubernetes.io/audit, pod-security.kubernetes.io/warn) using kubectl get namespace commands or API queries.
- Verify that the 'enforce' label is set to 'restricted' for all namespaces containing application workloads or third-party services.
- Attempt to deploy a test pod manifest that violates restricted policy constraints (e.g., privileged: true, hostNetwork: true, or runAsUser: 0) in a sample namespace and confirm the deployment is blocked with appropriate error messages.
- Review existing pod specifications across all namespaces by sampling at least 10% of running pods or all pods in high-risk namespaces, validating compliance with restricted profile requirements including securityContext settings.
- Examine audit logs or Pod Security Admission webhook logs for the past 90 days to identify any policy violations, exemptions granted, or configuration changes that weakened enforcement.
- Interview DevOps and platform engineering teams to confirm processes for exception handling, document any approved exemptions with business justification, and verify exemptions are scoped narrowly by namespace or workload.
Where this control is tested