Detections
Analytics

5.5.5 Verify Shielded GKE Nodes are enabled for GKE clusters

Information

Verify Shielded GKE Nodes are enabled for GKE clusters to provide stronger node identity and integrity protections for worker nodes. Shielded GKE Nodes help ensure that worker nodes are based on trusted boot components and can be cryptographically verified by the GKE control plane before joining the cluster.

Shielded GKE Nodes help protect clusters from node impersonation and boot level compromise by using Shielded VM capabilities to provide verifiable node identity and integrity. Without this protection, an attacker who compromises a workload or node could attempt to access bootstrap credentials and impersonate a node in the cluster.

For stronger node hardening, Shielded GKE Nodes should be used with Secure Boot and Integrity Monitoring where supported by the workload and node pool design. Secure Boot validates boot components during startup, while Integrity Monitoring validates the boot sequence against a known baseline and records pass or fail results in Cloud Logging.

Solution

Enable Shielded GKE Nodes for any GKE cluster where the audit result is not true. This updates the cluster so worker nodes are recreated as Shielded VMs and can be cryptographically verified by the GKE control plane before joining the cluster.

gcloud container clusters update $CLUSTER_NAME \\
 --location $LOCATION \\
 --project $PROJECT_ID \\
 --enable-shielded-nodes

Rerun the audit command and confirm that shieldedNodes.enabled returns true . Enabling Shielded GKE Nodes on an existing cluster immediately recreates the control plane and recreates worker nodes in a rolling manner while respecting maintenance availability, so plan the change during an approved maintenance window.

Impact:

Enabling Shielded GKE Nodes on an existing cluster recreates the control plane and recreates worker nodes as Shielded VMs in a rolling manner. The control plane update can occur immediately, while worker node recreation respects maintenance availability and uses the configured node upgrade strategy. Plan the change during an approved maintenance window and validate workload disruption controls such as replicas, PodDisruptionBudgets, and surge settings.

If maintenance availability prevents worker nodes from being recreated after the control plane update, node registration issues or temporary disruption can occur until the node pools are updated. Secure Boot can also affect workloads that depend on unsigned third party kernel modules, especially on Ubuntu node pools, so test those dependencies before enabling Secure Boot as part of the broader Shielded node hardening configuration.

See Also

https://workbench.cisecurity.org/benchmarks/24956

Item Details

Category: CONFIGURATION MANAGEMENT

References: 800-53|CM-6, 800-53|CM-7, CSCv7|5.3, CSCv7|18.11

Plugin: GCP

Control ID: 0a63c07cacf91e3dff05cb7797c69bbae6c9e6fec6f4afa0dc26548567fbaca8