> For the complete documentation index, see [llms.txt](https://docs.forestall.io/fsprotect/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/fsprotect/edges/gcp/gcp_can_impersonate_sa.md).

# GCP\_CAN\_IMPERSONATE\_SA

## Summary

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

## Description

`GCP_CAN_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_CAN_ACT_AS_SA` (which requires a compute vehicle), `GCP_CAN_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>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.forestall.io/fsprotect/edges/gcp/gcp_can_impersonate_sa.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.