Cross-cloud attack path: AWS role into GCP

Severity: critical when the entry point admits anyone, or the path ends at something privileged or at data. High otherwise.

What it means

A path that starts outside your clouds and ends in a different cloud from the one it entered.

github.com/acme/api @ refs/heads/main
  → role/ci-deploy                    sts:AssumeRoleWithWebIdentity
    → [gcp] data-pipeline@acme-prod   BigQuery datasets

Why no other scanner reports this

Your AWS scanner stops at role/ci-deploy. From inside AWS, that role is correctly configured: exact subject, correct audience, modest permissions. Nothing to report.

Your GCP scanner sees a workload identity binding admitting "some AWS role". From inside GCP, that is a named principal, not a wildcard. Nothing to report.

Neither of them is wrong. Each has full visibility of its half and no way to see the other. The path only exists when you put the two halves side by side, and nothing does that by default.

How the two halves are joined

Two mechanisms carry a caller across the boundary, and both leave enough behind to match on:

AWS into GCP. A GCP workload identity pool with an AWS provider records the caller's assumed-role ARN as the subject: arn:aws:sts::111122223333:assumed-role/ci-deploy/session. frontdoor resolves that to the canonical role ARN the AWS collector already knows about.

GCP into AWS. An AWS trust policy federating to accounts.google.com carries the service account's numeric unique id, not its email. The join needs the GCP side to translate it.

What is deliberately not joined

If only one cloud was scanned, no edge is drawn. An AWS account you never pointed the tool at is genuinely outside, and inventing a node we know nothing about would be worse than stopping. The door is reported as an ordinary entry point instead.

Scanning both clouds in one run is what makes this rule work:

frontdoor scan --aws --gcp --gcp-project acme-prod

How to fix it

1. Decide whether the boundary is meant to be crossed at all. Often the answer is yes — a data pipeline that reads from both clouds is a normal thing to build. The finding is not that it is wrong; it is that nobody was looking at it end to end.

2. The crossing point is named in the finding. That is the one place a reader can cut the path in half.

3. Tighten the entry point. It is almost always the weakest link, and fixing it closes every chain through it.

4. Cut the terminal's permissions if every hop is genuinely needed.