Trace Google service account impersonation across every hop

Map the caller and target identity

A service account can look ordinary in a resource policy while several people or workloads are able to act as it. The resource's role assignment describes what that identity may do. It does not, on its own, describe every caller that can obtain credentials for the identity. An impersonation review has to connect both sides.

Begin with a target service account and one important resource action. Identify its resource permissions, then work backward through the callers that can create credentials for it. Record the service account's full resource name and the principal identifiers at each step. Do not substitute a list of display names for the actual binding scope and membership evidence.

The resulting record is a graph of authority, not a claim that every possible path has been enumerated. Mark unresolved group membership, inherited grants and identities outside the examined scope. An edge that has not been investigated should remain visibly unresolved; drawing the graph without it would make the evidence look narrower than the review actually established.

Source. Primary documentation ^{[1] [2] [3] [4] [5]}. Accessed August 28, 2026.

Method. Original hypothetical delegation chain based on Google's documented API requirements. Credential-creation edges and resource permissions are distinct. No account identifiers, token values or measured counts are shown.

Accessible table and figure data

Figure 1 accessible table

Edge or record	Required review	Scope limit
Caller to first account	Token creation authority	Prefer a named target account
Delegated account to next account	Token Creator on next account	Check every hop
Target account to resource	Resource role and conditions	Can extend outside its home project
Token creation event	IAM Data Access configuration	May be absent unless enabled
Resource action event	Delegation fields and caller	Service-specific attribution

Figure 1 accessible table

Edge or record	Required review	Scope limit
Caller to first account	Token creation authority	Prefer a named target account
Delegated account to next account	Token Creator on next account	Check every hop
Target account to resource	Resource role and conditions	Can extend outside its home project
Token creation event	IAM Data Access configuration	May be absent unless enabled
Resource action event	Delegation fields and caller	Service-specific attribution

Download imageDownload table CSV

Distinguish attaching from impersonating

Google distinguishes the Service Account User role, which includes iam.serviceAccounts.actAs, from Service Account Token Creator, which includes permissions for creating access tokens, signing data and related delegation operations. Attaching a service account to a resource is not the same operation as directly generating an access token for it. ^[1]

Inventory these capabilities separately. A deployment operator may need to attach a particular identity to a workload without needing a general-purpose impersonation path from their workstation. Conversely, a controlled automation process may need to generate a token without administering the workload resource itself. The business justification should identify the operation being authorized.

Google warns that granting Token Creator at project scope can permit impersonation of service accounts across that project, including accounts with authority elsewhere. A review focused only on the project containing the binding can therefore miss the target account's resource reach. Prefer examining the grant at the service-account level and justify any broader scope explicitly. ^[2]

For each binding, record why the caller needs the capability, which target identities it reaches and who may change the binding or its membership. This exposes an important ownership question: the person approving the impersonation grant may not own every resource reachable by the target identity.

Review each delegation edge

The generateAccessToken API supports a delegates chain. Google documents that each service account in the sequence needs Token Creator authority on the next, and the last needs it on the target. The resource names use the required projects/-/serviceAccounts/... form. These are separate edges to review, not one undifferentiated “impersonation enabled” setting. ^[3]

Create a row for the originating principal, every intermediary and the target. Include the binding scope and the evidence used to establish each edge. Then add the target's resource grant as a different relationship. A token-creation permission authorizes obtaining an identity credential; the resource grant determines what that identity can attempt afterward.

Look for edges that exist only because of a wider inherited grant. A narrowly named chain in an application configuration does not prove that the caller lacks alternative paths. Where the review cannot enumerate those alternatives, state the limit and identify the next evidence source needed. Avoid describing the application's configured path as the only possible path without checking the surrounding authority.

Set token lifetime in context

For access tokens generated by the cited API, Google documents a default maximum lifetime of one hour and an organization-policy option allowing up to 12 hours for permitted service accounts. These values are API limits, not measurements of how long an attacker would retain useful access in a particular environment. ^[3]

Record the requested lifetime, the applicable organization-policy exception if any and the reason the job needs that duration. Compare the lifetime with the job's actual operating model. A batch process that refreshes credentials and an offline process that must finish with one token create different operational requirements; neither should receive a duration merely because it is the largest available.

Temporary credentials also leave a control-plane question: who can request another token? A short lifetime does not answer that question when the impersonation grant remains available. The review should therefore contain separate decisions about renewal authority, token storage and the procedure for withdrawing the relevant grants when an identity is no longer trusted.

Join issuance evidence to resource activity

Google classifies IAM Credentials API audit records under Data Access logging. Its guidance explains the configuration relationship with the IAM API rather than treating credential generation as an independently enabled service log. Verify that the necessary audit configuration is active before assuming an impersonation event will be available during an investigation. ^[4]

The service-account audit examples show how token creation and later resource activity can identify the target account and, where supplied, delegation information such as serviceAccountDelegationInfo. Google also documents service differences. Do not promise that every downstream service record reconstructs every caller in the chain. ^[5]

Preserve issuance evidence and resource evidence as separate records. Relate them using the identifiers, time bounds and service fields actually available, while keeping the inference visible. A target account appearing in both places may support a hypothesis, but a complete attribution statement needs enough context to distinguish concurrent callers and other credentials associated with that identity.

Review the chain as it changes

An impersonation graph needs change triggers. Revisit it when a target account receives new resource permissions, when a caller group gains members, when a delegation binding changes or when an application adds another intermediary. Any of these changes can alter the reachable authority without renaming the service account.

A useful acceptance exercise starts with an approved caller and includes a caller that should be excluded. Use a harmless resource action and retain the token-creation result separately from the resource-action result. Keep credentials out of the evidence package. If an intermediate edge is removed during an authorized test, record which configured path fails and which alternative paths were outside the exercise.

The handoff to operations should identify a binding owner for every edge and a resource owner for the target's important grants. When a token-generation alert arrives, those owners can then answer whether the caller, path and requested lifetime were expected. A graph without that ownership may describe access accurately while still leaving the responder unable to make a safe containment decision.