Skip to main content

More Info:

Enable Secure Boot on Shielded GKE nodes so only signed, trusted boot components are permitted to load. This blocks unsigned kernel modules and boot-level malware.

Risk Level

Medium

Address

Security

Compliance Standards

  • CIS GKE

Triage and Remediation

Remediation

Manual Steps

  1. On any machine with gcloud configured, list node pools and identify which are non‑compliant:
    Review the shieldedInstanceConfig field; node pools where enableSecureBoot is missing or false need remediation.
  2. For each node pool, gather full Shielded VM details to confirm status:
    Document which workloads and namespaces currently run on each non‑compliant pool.
  3. Plan the remediation (per cluster / environment): decide which node pools will be replaced, the desired machine type, size, labels/taints, and maintenance window; validate that enabling Secure Boot is supported for the node image and machine type used in your organization.
  4. Create a new compliant node pool with Secure Boot enabled (repeat per replacement pool):
    Add any required flags (e.g., --machine-type, --num-nodes, --node-labels, --node-taints) to match your existing pool’s configuration.
  5. Migrate workloads from each non‑compliant node pool to its new Secure Boot pool using your standard process (e.g., update node selectors/affinity, taints/tolerations, PodDisruptionBudgets, and scale settings), then drain the old nodes and delete the non‑compliant pool:
  6. Verify remediation for all pools:
    Confirm every active node pool shows Secure Boot enabled in shieldedInstanceConfig.
kubectl cannot enable Secure Boot for Shielded GKE nodes, because this setting is only configurable on the node pool via GCP (Cloud Console, gcloud, or IaC such as Terraform). Use those cloud-provider tools instead and follow the guidance in the Manual Steps section to recreate node pools with --shielded-secure-boot and migrate workloads.