Information
Enable the GKE metadata server on GKE node pools to support Workload Identity Federation for GKE and reduce workload access to the full Compute Engine metadata server. This setting helps workloads use Kubernetes based identity federation instead of relying on broad node service account credentials.
The Compute Engine metadata server exposes VM metadata and credentials associated with the node service account. If workloads can access those endpoints directly, they might obtain credentials or metadata that were intended for the node rather than the workload. This is especially risky in shared or multi-tenant clusters where different workloads run on the same node.
When the GKE metadata server is enabled on a node pool, it provides the subset of metadata endpoints required by Kubernetes workloads and intercepts requests to the metadata endpoint for normal pods. This supports Workload Identity Federation for GKE by allowing workloads to receive federated credentials based on their Kubernetes service account identity instead of using node level IAM permissions.
Solution
Enable Workload Identity Federation for GKE on the cluster if the audit shows that no workload pool is configured. This is required before the GKE metadata server can be enabled on Standard node pools.
gcloud container clusters update $CLUSTER_NAME \\
--location=$LOCATION \\
--project=$PROJECT_ID \\
--workload-pool=$PROJECT_ID.svc.id.goog
Enable the GKE metadata server on existing node pools that require workload access to Google Cloud APIs. Existing node pools are not automatically updated when the cluster setting is enabled, so each existing node pool must be updated or replaced.
gcloud container node-pools update $NODE_POOL \\
--cluster=$CLUSTER_NAME \\
--location=$LOCATION \\
--project=$PROJECT_ID \\
--workload-metadata=GKE_METADATA
After remediation, rerun the audit command and confirm that each applicable node pool reports GKE_METADATA . Review workloads that previously relied on direct Compute Engine metadata server access or node service account credentials, because enabling the GKE metadata server can require workload identity and IAM permission updates.
Impact:
Enabling the GKE metadata server can affect workloads that previously depended on direct access to the Compute Engine metadata server or node service account credentials. Those workloads should be updated to use dedicated Kubernetes service accounts with Workload Identity Federation for GKE and appropriate IAM allow policies. Pods that run with hostNetwork: true do not use Workload Identity Federation for GKE in the normal path and are routed to the Compute Engine metadata server, so those workloads should be reviewed separately.