More Info:
Enable the GKE Metadata Server so workloads use Workload Identity and legacy metadata endpoints are not exposed to pods. Legacy metadata endpoints can leak node service-account credentials.Risk Level
CriticalAddress
SecurityCompliance Standards
- CIS GKE
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify clusters and capture current Workload Identity / metadata settings
- Run on any machine with
gcloudaccess: - Note whether
workloadIdentityConfig.workloadPoolis set and whether eachnodePools[].config.workloadMetadataConfig.modeisGKE_METADATA_SERVER.
- Run on any machine with
-
Decide on cluster-level Workload Identity configuration
- If
workloadIdentityConfig.workloadPoolis unset or empty, decide whether this cluster should use Workload Identity (recommended for production/security‑sensitive clusters). - If yes, enable Workload Identity for the cluster (no node pools are changed yet):
- Record the decision and any clusters intentionally left without Workload Identity (e.g., legacy/test).
- If
-
Review each node pool’s metadata mode and plan changes
- For each cluster where Workload Identity is (or will be) enabled, list node pools and their metadata mode:
- Identify node pools where
modeis notGKE_METADATA_SERVER(e.g.GCE_METADATA). - For each such pool, confirm with workload owners whether any workloads still rely on node service account metadata access; plan remediation (migrating to Workload Identity) before flipping the setting.
- For each cluster where Workload Identity is (or will be) enabled, list node pools and their metadata mode:
-
Enable GKE Metadata Server on selected node pools
- When you are ready to cut over a node pool, run:
- Repeat for each node pool you decided to protect with the metadata server.
- Be aware this can trigger node recreation/rolling updates depending on configuration and may affect workloads that used legacy metadata endpoints.
- When you are ready to cut over a node pool, run:
-
Adjust workloads to use Workload Identity (if needed)
- For workloads that previously used node service account credentials, identify required Google Cloud IAM permissions and bind them to Kubernetes service accounts using Workload Identity.
- Evidence collection:
- Update manifests/IaC so pods mount and use the correct Kubernetes service accounts with the proper
iam.gke.io/gcp-service-accountannotation (per your internal standards and Google’s documentation).
-
Verify remediation and document exceptions
- Re-run the audit for each cluster:
- Confirm that for all intended node pools,
modeisGKE_METADATA_SERVER. - Document any clusters/node pools where GKE Metadata Server is intentionally not enabled, including owners, justification, and a review date.
- Re-run the audit for each cluster:
Using kubectl
Using kubectl
kubectl cannot enable the GKE Metadata Server or configure Workload Identity, because this setting is managed at the GKE control-plane/node-pool level via Google Cloud (gcloud CLI, Console, or IaC), not via Kubernetes API objects. Use the cloud provider configuration steps described in the Manual Steps section to remediate this finding.
Automation
Automation
- Ensure
gcloudandjqare installed and authenticated. - Set your project:
gcloud config set project YOUR_PROJECT_ID - Save the script as
check_gke_metadata_server.sh, make it executable:
chmod +x check_gke_metadata_server.sh - Run:
./check_gke_metadata_server.sh
- Line:
Workload Identity: DISABLED (identityNamespace is not set)
→ Cluster not configured for Workload Identity. - Any node pool line where
WORKLOAD METADATA MODEisGCE_METADATAorUNSET
→ That node pool is not using the GKE Metadata Server and still exposes the legacy metadata endpoint.

