More Info:
Pod Security Policy Should Be Used To Prevent Privileged Containers Where Possible And Enforce Namespace And Workload Configurations.Risk Level
LowAddress
SecurityCompliance Standards
- CIS GKE
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify clusters and current PSP setting
- On any machine with
gcloudconfigured for your GCP project, list clusters and check whether PSP is enabled: - If the value is empty or
false, PSP is not enabled on that cluster.
- On any machine with
-
Review current use of privileged features in workloads
- On any machine with
gcloudandkubectlaccess, inspect workloads that might require elevated privileges: - Note namespaces and workloads that rely on privileged, hostPID, hostNetwork, hostIPC, or hostPath volumes; these will need either exceptions or refactoring before strict policies are enforced.
- On any machine with
-
Decide PSP (or modern equivalent) strategy for the cluster
- For clusters running a GKE version that still supports PodSecurityPolicy and where you want to enforce it at the control-plane level, plan PSPs that:
- Deny privileged containers and host namespaces by default.
- Allow only specific system namespaces (for example,
kube-system) or known DaemonSets to use required privileges.
- For newer clusters or where PSP is deprecated/removed, decide whether to instead use the built‑in Pod Security Admission (
pod-security.kubernetes.io/*labels on namespaces) or a policy engine such as GKE Policy Controller (OPA/Gatekeeper).
- For clusters running a GKE version that still supports PodSecurityPolicy and where you want to enforce it at the control-plane level, plan PSPs that:
-
Enable or adjust Pod Security / policy enforcement at the control-plane
- If the cluster supports PSP and you decide to use it, enable PSP via the control-plane configuration from any machine with
gcloudaccess: - If PSP cannot be enabled (for example, because it is not supported in your GKE version), configure an alternative:
- Namespace Pod Security Admission levels:
- Or enable and configure GKE Policy Controller via the GKE console or
gcloud alpha container hub config-managementcommands, according to your organization’s policy.
- Namespace Pod Security Admission levels:
- If the cluster supports PSP and you decide to use it, enable PSP via the control-plane configuration from any machine with
-
Implement and test policy scope to avoid disruption
- Begin with non-production namespaces:
- Apply restrictive settings (PSP or Pod Security Admission labels / Policy Controller constraints).
- Attempt to deploy workloads that should be allowed and disallowed, and confirm behavior matches expectations.
- For workloads that legitimately need higher privileges, design narrowly scoped exceptions (dedicated PSPs, less restrictive namespace labels, or specific policy constraints) and validate those workloads can still run.
- Begin with non-production namespaces:
-
Verify and document the final configuration
- Confirm PSP is enabled at the cluster level (if applicable):
- List active Pod Security Policies (if in use):
- For Pod Security Admission, verify namespace labels:
- For Policy Controller, list constraint templates and constraints:
- Record which mechanism is in use, which namespaces are protected, and any approved exceptions for future audits.
- Confirm PSP is enabled at the cluster level (if applicable):
Using kubectl
Using kubectl
kubectl cannot enable or configure Pod Security Policy because this setting is controlled at the GKE cluster (managed control plane) level via gcloud/console/IaC. To remediate, follow the guidance in the Manual Steps section, which covers enabling Pod Security Policy through the cloud provider configuration.
Automation
Automation

