Skip to main content

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

Critical

Address

Security

Compliance Standards

  • CIS GKE

Triage and Remediation

Remediation

Manual Steps

  1. Identify clusters and capture current Workload Identity / metadata settings
    • Run on any machine with gcloud access:
    • Note whether workloadIdentityConfig.workloadPool is set and whether each nodePools[].config.workloadMetadataConfig.mode is GKE_METADATA_SERVER.
  2. Decide on cluster-level Workload Identity configuration
    • If workloadIdentityConfig.workloadPool is 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).
  3. 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 mode is not GKE_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.
  4. 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.
  5. 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-account annotation (per your internal standards and Google’s documentation).
  6. Verify remediation and document exceptions
    • Re-run the audit for each cluster:
    • Confirm that for all intended node pools, mode is GKE_METADATA_SERVER.
    • Document any clusters/node pools where GKE Metadata Server is intentionally not enabled, including owners, justification, and a review date.
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.
How to run (any machine with gcloud access):
  1. Ensure gcloud and jq are installed and authenticated.
  2. Set your project:
    gcloud config set project YOUR_PROJECT_ID
  3. Save the script as check_gke_metadata_server.sh, make it executable:
    chmod +x check_gke_metadata_server.sh
  4. Run:
    ./check_gke_metadata_server.sh
Output indicating a problem:
  • Line: Workload Identity: DISABLED (identityNamespace is not set)
    → Cluster not configured for Workload Identity.
  • Any node pool line where WORKLOAD METADATA MODE is GCE_METADATA or UNSET
    → That node pool is not using the GKE Metadata Server and still exposes the legacy metadata endpoint.