Metadata Server SSRF and Default Scopes
How Metadata Server SSRF and Default Scopes works
Server‑side request forgery (SSRF) to the GCE metadata server (http://metadata.google.internal) can steal access tokens for the attached service account. Broad default OAuth scopes on the default compute service account (e.g., cloud-platform) widen impact to many APIs. Similar risks exist for GKE nodes and workloads if pods can reach the node metadata server and Workload Identity is not used.
Metadata Server SSRF and Default Scopes in practice
Fetch Token (On VM/Workload)
curl -H 'Metadata-Flavor: Google' \
'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token'Inspect Scopes
gcloud compute instances describe <name> --zone <zone> --format='value(serviceAccounts[0].scopes)'
gcloud compute instances describe <name> --zone <zone> --format='value(serviceAccounts[0].email)'How to fix and prevent Metadata Server SSRF and Default Scopes
- Minimize scopes and avoid default SAs
- Use custom service accounts per workload; limit scopes to only needed APIs (or rely on IAM without scopes in newer platforms).
- Block SSRF to metadata
- Filter egress to
169.254.169.254/metadata.google.internal; validate URLs in apps; add allow‑lists.
- Filter egress to
- Prefer Workload Identity
- On GKE, enable Workload Identity so pods get short‑lived tokens instead of node SA tokens; avoid metadata exposure to pods.
Last updated
