> For the complete documentation index, see [llms.txt](https://docs.forestall.io/forestall/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.forestall.io/forestall/edges/gcp/gcp_impersonate_sa.md).

# GCP\_IMPERSONATE\_SA

## Summary

|                            |                                        |
| -------------------------- | -------------------------------------- |
| **Forestall ACL Alias**    | GCP\_IMPERSONATE\_SA                   |
| **GCP Alias**              | Persistence & Impersonation            |
| **Affected Object Types**  | Service Accounts                       |
| **Exploitation Certainty** | Certain                                |
| **Granting Roles**         | `roles/iam.serviceAccountTokenCreator` |

## Description

`GCP_IMPERSONATE_SA` indicates that an identity holds `iam.serviceAccounts.getAccessToken` on a GCP **Service Account**, typically via `roles/iam.serviceAccountTokenCreator`. This is the most direct path to full SA impersonation: the attacker can call the IAM **generateAccessToken** API from anywhere on the internet and receive a short-lived OAuth2 access token valid for 1 hour.

Unlike `GCP_ACT_AS_SA` (which requires a compute vehicle), `GCP_IMPERSONATE_SA` enables **direct API-based token generation** with no infrastructure dependency. An attacker needs only network access to the IAM API to fully impersonate the target SA.

**Key abuse scenarios:**

* Generate access tokens for a high-privilege SA and call any GCP API as that SA.
* Chain impersonation: generate a token for SA-A, then use SA-A's token to impersonate SA-B (if SA-A has token creator on SA-B).
* Generate ID tokens for service-to-service authentication to GCP-hosted services.

## Identification

### gcloud CLI

```bash
# Find who has token creator role at project level
PROJECT_ID="my-project"
gcloud projects get-iam-policy $PROJECT_ID --format=json | \
  jq '.bindings[] | select(.role | test("serviceAccountTokenCreator")) | {role: .role, members: .members}'

# Check SA-level token creator grants
for SA in $(gcloud iam service-accounts list --project=$PROJECT_ID --format="value(email)"); do
  POLICY=$(gcloud iam service-accounts get-iam-policy $SA --format=json 2>/dev/null)
  BINDINGS=$(echo $POLICY | jq '.bindings[] | select(.role == "roles/iam.serviceAccountTokenCreator")')
  if [ ! -z "$BINDINGS" ]; then
    echo "=== $SA ===" && echo $BINDINGS
  fi
done
```

### GCP Console

1. Open **GCP Console** → **IAM & Admin** → **IAM**.
2. Check for principals with `Service Account Token Creator` role.
3. Go to **IAM & Admin** → **Service Accounts**.
4. Select a service account → **Permissions** tab.
5. Check for principals with `Service Account Token Creator` role.

## Exploitation

### gcloud CLI

```bash
# Generate an access token for a target SA directly (no infrastructure needed)
TARGET_SA="high-priv@target-project.iam.gserviceaccount.com"

# Using gcloud (works if current identity has token creator on target SA)
gcloud auth print-access-token --impersonate-service-account=$TARGET_SA

# Using the IAM API directly
ACCESS_TOKEN=$(gcloud auth print-access-token)
curl -X POST \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"scope": ["https://www.googleapis.com/auth/cloud-platform"], "lifetime": "3600s"}' \
  "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/${TARGET_SA}:generateAccessToken"

# Chain impersonation through multiple SAs
gcloud auth print-access-token \
  --impersonate-service-account=sa-a@project.iam.gserviceaccount.com,sa-b@project.iam.gserviceaccount.com
```

With the resulting token, all GCP API calls are made as the target SA.

## Mitigation

1. **Restrict `roles/iam.serviceAccountTokenCreator`** — this role should only be granted to specific, audited automation identities that explicitly require delegation.
2. **Avoid project-level token creator grants** — scope to specific SA resources rather than all SAs in a project.
3. **Monitor for chained impersonation paths** using Policy Analyzer.
4. **Use Workload Identity Federation** for external workloads instead of granting token creator to service accounts.

## Detection

| Log Type    | Method                | Key Fields                                                        |
| ----------- | --------------------- | ----------------------------------------------------------------- |
| Data Access | `GenerateAccessToken` | `resource.type=service_account`, `methodName=GenerateAccessToken` |

```bash
gcloud logging read \
  'protoPayload.methodName="GenerateAccessToken"' \
  --project=$PROJECT_ID \
  --format="table(timestamp, protoPayload.authenticationInfo.principalEmail, protoPayload.resourceName)"
```

Alert on:

* `GenerateAccessToken` calls on privileged SAs by non-automation identities.
* Impersonation chains — token generation where the caller is itself a service account.

## References

* <https://https://docs.cloud.google.com/iam/docs/service-account-impersonation>