PS Product SecurityKnowledge Base

🟨 GCP Cloud Attack Chains

Intro: In GCP, the decisive expansion step is commonly the move from code execution to service account-backed API access. Metadata tokens, workload identity federation, build identities, and over-broad IAM bindings dominate many real attack paths.

What this page includes

  • common GCP-native attack chains
  • service account and workload identity expansion patterns
  • where Cloud Audit Logs and GKE logs should answer the scoping questions
  • practical containment priorities

GCP Cloud Attack Chain Figure: Common GCP sequence from workload foothold to service-account abuse and project control.

Chain 1 — workload compromise to metadata server token to broader API abuse

Typical flow

  1. the attacker gains command execution or SSRF in a Compute Engine, GKE, or Cloud Run style workload;
  2. they obtain credentials through the local metadata or identity path available to the workload;
  3. they use the token against Secret Manager, Cloud Storage, Artifact Registry, Cloud Build, or IAM-relevant APIs;
  4. they enumerate what the service account can reach;
  5. they expand into data access, deployment control, or further impersonation.

Why this chain matters

GCP is usually clean when service accounts are narrow and separate. It becomes fragile when one service account is reused broadly, or when workloads inherit permissions because “it was easier than designing the boundary well.”

Chain 2 — leaked service account key or build credential to project-wide discovery

Typical flow

  1. the attacker finds a JSON service account key, build token, or exported credential in code, logs, or storage;
  2. they authenticate directly without touching the application again;
  3. they enumerate IAM bindings, projects, storage, secrets, registries, and cluster paths;
  4. if they can impersonate stronger identities or modify build and deploy resources, the incident escalates fast.

Why defenders should dislike service account keys

Static keys extend the attacker time horizon. Even if the first host is gone, the key may keep working until it is explicitly rotated or disabled.

Chain 3 — over-privileged GKE workload identity to secret and data exposure

Typical flow

  1. the attacker compromises a pod;
  2. they abuse the Kubernetes-to-Google identity mapping for that workload;
  3. they call GCP APIs as the mapped identity;
  4. they read secrets, storage objects, or registry material;
  5. they pivot into more sensitive namespaces or projects using recovered information.

What to hunt

  • GKE audit logs around secret reads, pod creation, pod exec patterns, or RBAC changes;
  • Cloud Audit Logs for sensitive API calls that the workload did not normally make;
  • Artifact Registry and Cloud Build actions close to the compromise window.

Chain 4 — CI/CD and Artifact Registry compromise to supply-chain persistence

Typical flow

  1. the attacker gets a build credential, repository token, or access to a build runner;
  2. they push a malicious image or alter build steps;
  3. the poisoned artifact gets deployed into GKE or another runtime path;
  4. the compromise persists even after the original CI foothold is removed.

Why it is important

In GCP-heavy delivery stacks, Cloud Build, Artifact Registry, and deployment automation can become the shortest route to wide runtime impact.

Chain 5 — public exposure plus poor segmentation to project expansion

Typical flow

  1. a public workload, bucket, or service leaks sensitive operational detail;
  2. the attacker gains initial access or recovers config and credential hints;
  3. they pivot into service account-backed APIs;
  4. they enumerate data stores and deployment paths;
  5. they establish persistence through additional IAM grants, build path control, or long-lived credentials.

GCP hunting priorities

Start with Cloud Audit Logs

Admin Activity audit logs are always enabled. They should answer:

  • who changed IAM or deployment state?
  • which service account was used?
  • what project, cluster, or secret path did it touch?

If Data Access logs are enabled, the investigation becomes much stronger because you can validate secret and data reads instead of inferring them.

Then join runtime evidence

Correlate with:

  • GKE audit logs for Kubernetes-side activity;
  • GKE and container logs for execution context;
  • build and registry timelines if image poisoning is suspected.

GCP CLI pivots

# confirm active identity context
 gcloud auth list

# recent audit log examples for IAM or cluster activity
 gcloud logging read \
  'logName:"cloudaudit.googleapis.com" AND severity>=DEFAULT' \
  --limit=50 --format=json

# inspect GKE cluster posture
 gcloud container clusters describe <cluster-name> --location <region-or-zone>

# list IAM policy bindings on a project
 gcloud projects get-iam-policy <project-id>

Defensive defaults that break GCP chains early

  • prefer workload identity federation over long-lived service account keys;
  • keep service accounts narrowly scoped and environment-specific;
  • enable the right Cloud Audit Logs and keep them retained somewhere useful;
  • separate build identities from runtime identities;
  • review Artifact Registry and build permissions as carefully as production data access;
  • keep public exposure, metadata reachability, and secret access intentionally constrained.