Information
Pod Security Standards provide predefined pod security profiles that can be applied to GKE Standard workload namespaces through the built in PodSecurity admission controller. At minimum, workload namespaces should enforce the baseline profile, with restricted used where stronger pod hardening is required.
Without enforce mode applied to workload namespaces, GKE can allow pods that violate the intended Pod Security Standard to be admitted. The baseline profile helps prevent known privilege escalation patterns, while the restricted profile adds stronger controls such as requiring allowPrivilegeEscalation=false, dropping all Linux capabilities, running as non root, and using an allowed seccomp profile. warn and audit are useful for rollout and visibility, but they do not block noncompliant pods.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance.
Solution
Update workload namespaces so Pod Security enforcement is applied consistently through namespace labels. Use restricted where workloads can support it, and use baseline where compatibility requires a less restrictive profile.
-
Identify all namespaces that host user workloads and confirm each one uses pod-security.kubernetes.io/enforce=baseline or pod-security.kubernetes.io/enforce=restricted.
-
Test the selected profile before enforcement using server side dry run, especially when moving from no enforcement to restricted.
-
Remediate violating workload specs by updating security contexts, privilege settings, host namespace usage, volume types, and Linux capability settings.
kubectl edit deployment/<deployment-name> -n $NAMESPACE
kubectl rollout restart deployment/<deployment-name> -n $NAMESPACE
- Apply the enforcement label only after violations are resolved or formally approved as exceptions.
kubectl label --overwrite namespace $NAMESPACE \\
pod-security.kubernetes.io/enforce=baseline
Or, for stricter enforcement:
kubectl label --overwrite namespace $NAMESPACE \\
pod-security.kubernetes.io/enforce=restricted
- Do not rely on warn or audit labels alone because they report violations but do not block noncompliant pod creation.
After remediation, update namespace provisioning standards so new workload namespaces receive the appropriate Pod Security enforcement label at creation. Periodically recheck namespace labels to confirm that enforcement remains in place as teams, applications, and environments change.
Impact:
Enforcing baseline or restricted can block workloads that require privileged containers, unsafe security context settings, or other pod configurations that violate the selected profile. Existing running pods are not terminated by PodSecurity, so it's important to test with warn and audit before moving workload namespaces to enforce.