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
MediumAddress
SecurityCompliance Standards
- CIS GKE
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
On any machine with
gcloudconfigured, list node pools and identify which are non‑compliant:Review theshieldedInstanceConfigfield; node pools whereenableSecureBootis missing orfalseneed remediation. -
For each node pool, gather full Shielded VM details to confirm status:
Document which workloads and namespaces currently run on each non‑compliant pool.
- 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.
-
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. -
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:
-
Verify remediation for all pools:
Confirm every active node pool shows Secure Boot enabled in
shieldedInstanceConfig.
Using kubectl
Using kubectl
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.Automation
Automation

