Skip to main content

More Info:

Pod Security Policy Should Be Used To Prevent Privileged Containers Where Possible And Enforce Namespace And Workload Configurations.

Risk Level

Low

Address

Security

Compliance Standards

  • CIS GKE

Triage and Remediation

Remediation

Manual Steps

  1. Identify clusters and current PSP setting
    • On any machine with gcloud configured 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.
  2. Review current use of privileged features in workloads
    • On any machine with gcloud and kubectl access, 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.
  3. 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).
  4. 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 gcloud access:
    • 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-management commands, according to your organization’s policy.
  5. 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.
  6. 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.
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.

Additional Reading: