Auditing GCP Service Account Impersonation Chains Before They Create Lateral Movement Paths

Each impersonation method has a different risk profile and requires different enumeration and detection approaches.

Method 1: iam.serviceAccounts.actAs IAM binding. The most direct impersonation method. When a principal (user, service account, or group) has the iam.serviceAccounts.actAs permission on a service account, they can call the generateAccessToken or generateIdToken API to obtain credentials for that service account. This permission is often granted implicitly via the roles/iam.serviceAccountUser role. The risk: any principal with actAs on Service Account B can call any API that Service Account B is authorized for.

Method 2: Domain-wide delegation (DWD). A service account with domain-wide delegation configured can impersonate any Google Workspace user in the domain for the delegated OAuth scopes. DWD is required for some G Suite API integrations, but a service account with DWD grants and broad OAuth scopes (e.g., https://www.googleapis.com/auth/gmail.readonly for all users) can read the email of any user in the organization. This is a high-privilege capability that often exists in environments with legacy G Suite integrations.

Method 3: Workload identity federation. Workload identity federation allows external identities (GitHub Actions tokens, AWS IAM roles, on-premises service accounts) to impersonate GCP service accounts without key files. Misconfigured federation trusts can allow broader external access than intended -- for example, a federation trust that allows any token from a GitHub organization's OIDC provider, rather than specifically scoped repository and workflow conditions.

Method 4: Service account key files. Downloaded JSON key files provide long-lived service account credentials that work without network connectivity to GCP. Key files do not expire unless the private key is rotated. Authentication using a key file generates Cloud Audit Logs entries attributable to the service account, not to the key holder -- making attribution difficult without additional logging. Key files that were downloaded and then forgotten represent indefinite impersonation access.

Enumeration produces a complete list of impersonation relationships. Run these commands across every project in the organization.

Enumerate all actAs bindings across an organization:

gcloud asset search-all-iam-policies \
  --scope="organizations/[ORG_ID]" \
  --query="roles/iam.serviceAccountUser OR roles/iam.serviceAccountTokenCreator OR policy.role.permissions:iam.serviceAccounts.actAs" \
  --format="json" | jq '.[] | {resource: .resource, bindings: .policy.bindings}'

This returns every IAM binding that grants actAs capabilities, across all projects in the organization.

Enumerate all service accounts with domain-wide delegation:

gcloud iam service-accounts list --project=[PROJECT_ID] --format="json" |   jq '.[] | select(.oauth2ClientId != null) | {email: .email, clientId: .oauth2ClientId}'

Service accounts with a non-null oauth2ClientId have DWD configured. Cross-reference with the Google Workspace Admin SDK to see which OAuth scopes are authorized for each service account.

Enumerate all workload identity federation pools and providers:

gcloud iam workload-identity-pools list --location="global" --project=[PROJECT_ID] --format="json"
gcloud iam workload-identity-pools providers list \
  --workload-identity-pool=[POOL_ID] \
  --location="global" --project=[PROJECT_ID] --format="json"

For each provider, review the attribute conditions to determine which external identities are trusted.

Enumerate active service account key files:

gcloud iam service-accounts keys list \
  --iam-account=[SA_EMAIL] --managed-by="user" --format="json" |   jq '.[] | {keyId: .name, created: .validAfterTime, expires: .validBeforeTime}'

User-managed keys (--managed-by=user) are the downloaded JSON key files. Google-managed keys are short-lived and managed automatically. List all user-managed keys across all service accounts in every project.

Cloud Audit Logs records impersonation events. The following log patterns indicate impersonation activity and require review.

Detecting actAs impersonation in Cloud Audit Logs:

Filter in Cloud Logging for impersonation events:

resource.type="service_account"
protoPayload.methodName="GenerateAccessToken" OR
protoPayload.methodName="GenerateIdToken"

The protoPayload.authenticationInfo.principalEmail field shows who requested the impersonation. The protoPayload.request.name field shows which service account was impersonated. Alert when any impersonation request originates from a principal outside the expected set of callers for that service account.

Detecting domain-wide delegation usage:

resource.type="service_account"
protoPayload.request.delegates!=""

The delegates field in the request indicates that the service account is acting on behalf of a specific Google Workspace user. Alert when delegation events occur for users who are not expected to have APIs called on their behalf, or when the OAuth scopes used exceed what is required for the integration.

Detecting unusual key file usage:

Authentication with a service account key file generates protoPayload.authenticationInfo.serviceAccountKeyName in the audit log. Alert when authentication using a service account key file occurs from an IP address that is not in the expected range for the application that uses that key.

Detecting impersonation chains:

A principal that generates access tokens for multiple different service accounts within a short time window is potentially exploring the impersonation graph. Build a detection that alerts when a single principal calls GenerateAccessToken for more than three different service accounts within one hour.

Remediation follows the same sequence regardless of which impersonation method is being addressed: document the legitimate use case, remove the over-broad grant, and replace it with a minimum-privilege alternative.

Remediation sequence for actAs bindings:

1. For each actAs binding found, contact the team that owns the binding. Determine whether it is actively used and what it is used for.
2. If unused: revoke immediately. gcloud projects remove-iam-policy-binding [PROJECT] --member=[PRINCIPAL] --role=roles/iam.serviceAccountUser
3. If used: replace with a more specific binding scoped to the minimum required service account. If Service Account A currently has actAs on all service accounts in the project, restrict it to actAs on only the specific service account it needs.

Remediation sequence for DWD grants:

1. In the Google Workspace Admin console, review the OAuth scopes authorized for each service account with DWD.
2. Remove DWD for service accounts where the integration no longer requires it.
3. For remaining DWD grants, reduce OAuth scopes to the minimum required. A service account that reads calendar events does not need gmail.readonly.

Remediation sequence for key files:

1. For each user-managed key file, determine whether it is actively used by checking recent authentication events in Cloud Audit Logs using the key ID.
2. For unused key files: delete immediately. gcloud iam service-accounts keys delete [KEY_ID] --iam-account=[SA_EMAIL]
3. For active key files: work with the application team to migrate to workload identity federation (for external callers) or actAs impersonation with short-lived tokens (for GCP-internal callers). Set a migration deadline -- 90 days is typical.
4. After migration: delete the key file.

After remediating existing impersonation chains, Organization Policy constraints prevent new ones from being created without explicit approval.

Disable service account key creation:

gcloud resource-manager org-policies set-policy \
  --organization=[ORG_ID] \
  disable-sa-key-creation-policy.json

Where the policy file contains:

{
  "constraint": "constraints/iam.disableServiceAccountKeyCreation",
  "booleanPolicy": { "enforced": true }
}

This prevents creation of new service account key files at the organization level. Applications that currently use key files must migrate before this policy is enforced.

Disable service account creation in production projects:

In GCP environments that use separate projects for different environments, restrict service account creation in production to the platform engineering team: constraints/iam.disableServiceAccountCreation on production projects, with exceptions for the infrastructure team's service account.

Require workload identity federation for external callers:

Enforce workload identity federation as the only mechanism for external callers (GitHub Actions, on-premises systems, other cloud providers) to authenticate to GCP. This is a cultural and process constraint rather than a technical one -- document the requirement in the infrastructure onboarding process and include it in code review checklists for new GCP integrations.

Monitor for new DWD grants:

Create a Cloud Monitoring alert policy on Cloud Audit Logs for any DWD grant creation event:

resource.type="service_account"
protoPayload.methodName="google.iam.admin.v1.UpdateServiceAccount"
protoPayload.request.service_account.oauth2_client_id!=""

This detects when DWD is enabled for a service account and routes it to the security team for review before the grant becomes operational.