This second part of the blog series continues the path to understanding principals and identities in Google Cloud Platform (GCP) Audit Logs. Part one introduced core concepts around GCP logging, the different identity types, service accounts, authentication methods, and impersonation.

Building on that foundation, this blog post will explore additional important identity categories useful for forensic investigations:

• Service Agents
• Workload Identities - Workload Identity Federation
• GKE Workload Identities - GKE Workload Identity Federation
• Workforce Identities – Workforce Identity Federation

Service Agents

Service Agents represent a special type of Service Account automatically created by Google whenever an associated Google API is enabled within a project. These accounts act on behalf of individual Google Cloud services and internal GCP processes to perform background tasks. Unlike regular customer-managed Service Accounts, which reside within user-owned projects and can be managed by customers, Service Agents are Google-managed identities residing within Google-owned projects. Their actions are transparently logged, and although customers can view and adjust their role bindings, the accounts themselves cannot be impersonated.

A typical Service Agent email begins with ‘service-’, such as service-<project-number>@service-networking.iam.gserviceaccount.com.

Service Agents vs. Regular Service Accounts:

‍

‍

For an in-depth explanation of Service Agents, refer to Kat Traxler’s detailed blog post: GCP Service Agents 201.

Below is an example showing an operation performed by the default Compute Engine service account, with the Compute Engine Service Agent appearing in the serviceAccountDelegationInfo section of the log:

‍

Workload Identities - Workload Identity Federation

What is Workload Identity Federation?

Workload Identity Federation allows external workloads and apps (outside of GCP) to securely interact with Google Cloud resources without needing service account keys. Typically, external apps use service account keys to access GCP, but these keys pose security risks if not handled correctly. Workload Identity Federation and Workload Identities eliminate the hassle and risks associated with managing these keys.

This approach specifically solves problems related to:

• Security Risks: Service account keys can have powerful credentials, and if they are compromised or mismanaged, they can lead to unauthorized access and serious security incidents.
• Complex Credential Management: Managing, rotating, and securing service account keys can become complicated and error-prone, especially as your organization grows.

Instead, Workload Identity Federation offers:

• Keyless Authentication: It replaces traditional service account keys with short-lived access tokens, improving security by reducing exposure.
• Integration with External Identity Providers: Workload Identity Federation supports identity providers (IdPs) such as AWS, Microsoft Entra ID, Okta, Active Directory Federation Services (AD FS). This integration simplifies authentication for workloads already using these platforms.

How does Workload Identity Federation work?

‍

Workload Identity Federation works by securely exchanging credentials from an external Identity Provider (IdP) with Google Cloud's Security Token Service (STS), eliminating the need for service account keys.

The typical authentication flow is:

1. ‍Authentication request:
   The external workload or application initiates authentication against an external Identity Provider, such as AWS or Entra ID.
2. External credentials returned:
   After successful authentication, the external Identity Provider provides credentials (tokens) to the application or workload.‍
3. Credentials sent to Google Cloud:
   The external workload forwards these credentials to Google's Security Token Service (STS).‍
4. GCP access token issued:
   Google's STS verifies the external credentials. After successful validation, it provides a short-lived federated access token, which grants temporary access to Google Cloud resources.‍
5. Impersonation using the access token:
   The external workload uses the provided federated token to impersonate a Google Cloud service account, allowing it to interact with GCP resources.

To facilitate this process, Workload Identity Federation uses workload identity pools and providers to manage and securely map external identities.

Tokens issued by external IdPs include attributes (often called claims), which Google’s Security Token Service (STS) maps to GCP-specific fields using attribute mappings. An essential attribute is google.subject, which uniquely identifies the external identity within Google Cloud IAM and Cloud Logging, providing clear traceability for security audits and forensic investigations.

Identifying Workload Identity Federation Token Exchange

To investigate access involving Workload Identity Federation, it's important to understand how external identities are recorded in Cloud Audit Logs.  Understanding how these identities are represented—especially through the mapped identity field—is key for accurate attribution and forensic clarity. The following example shows how Google's Security Token Service (STS) logs the token exchange and maps external identities into GCP.

Understanding the mapped_principal Concept:

When an external identity is authenticated, Google Cloud maps it to an internal identity format known as the mapped principal (mapped_principal). This representation appears in Cloud Logging and IAM and helps identify the external source, enabling transparency and traceability during investigations.

AWS External Entity

In the case of an AWS external identity, the principalSubject shows the original AWS ARN identity (e.g., arn:aws:sts::<ACCOUNT_ID>:assumed-role/<ROLE>/<SESSION_ID>). Google Cloud maps this identity to its internal representation in the mapped_principal field, which is formatted as a structured GCP workload identity resource. The log indicates that this event is a token exchange operation, as shown by the methodName google.identity.sts.v1.SecurityTokenService.ExchangeToken.

‍

‍

Example 2: Azure External Entity

For an Azure external identity, the Azure Managed Identity object ID appears as the principalSubject (e.g., a GUID such as b6112abb-5791-4507-adb5-7e8cc306eb2e).

Example from Google’s documentation:

‍

‍

Identifying Token Generation for Service Account Impersonation

After mapping the external identity within Google Cloud, it can use the GenerateAccessToken method to impersonate a specific service account. The log entry below illustrates this step. Here, the principalSubject represents the mapped GCP identity derived from the external AWS entity. Additionally, the request.name field identifies the GCP service account targeted for impersonation.

‍

‍

Identifying Workload Identity Impersonated Operations

After the impersonation, any actions performed using the impersonated service account will appear in the logs as regular operations—but they can still be traced back to the original external identity through the serviceAccountDelegationInfo field.

Two examples below demonstrate how to identify these impersonated operations and extract valuable forensic context:

AWS:

In the following example of an AWS workload identity, the principalEmail shows the impersonated service account, while the serviceAccountDelegationInfo.principalSubject field reveals the external AWS identity, including the account ID, IAM role, and session ID (the ARN essentially). This information is especially valuable during investigations, as the session ID allows analysts to trace activity back to a specific AWS session, user, or assumed role event.

‍

‍

Github:

In this example from a GitHub Actions workload identity, the impersonated service account again appears in the principalEmail, while the delegation chain identifies the workload identity from GitHub. The principalSubject includes the repository path and trigger type (such as pull_request), making it possible to link GCP activity back to specific events in a GitHub repository—critical when investigating CI/CD pipelines or automated workflows.

‍

‍

GKE Workload Identities – GKE Workload Identity Federation

What is GKE Workload Identity Federation?

Similar to Workload Identity Federation, GKE Workload Identity Federation allows workloads in Google Kubernetes Engine (GKE) clusters to authenticate to Google Cloud using Kubernetes-native identities—without using service account keys. It bridges Kubernetes Service Accounts (KSAs) with Google Service Accounts (GSAs), enabling secure, keyless access to GCP resources.

Understanding the Difference Between Kubernetes and GCP Service Accounts

Kubernetes Service Accounts (KSAs) and Google Cloud Service Accounts (GSAs) serve different purposes and operate at different scopes.

KSAs (Kubernetes Service Accounts) are scoped to the Kubernetes cluster and are used for in-cluster authentication and authorization. They control how workloads running in pods interact with other components inside the cluster, using Kubernetes RBAC.

GSAs (Google Cloud Service Accounts) are IAM-managed identities used to access GCP resources. In GKE, these accounts can be mapped to Kubernetes Service Accounts (KSAs) using Workload Identity, enabling keyless access from workloads running in the cluster.

‍

Binding Kubernetes and GCP Service Accounts

In Google Kubernetes Engine (GKE), Workload Identity binds Kubernetes Service Accounts (KSAs) to Google Cloud Service Accounts (GSAs), bridging Kubernetes-native authentication with Google IAM. Once configured, workloads using the KSA can authenticate as the GSA to access Google Cloud resources—securely and without needing embedded service account keys.

Permissions are centrally managed through IAM roles on the GSA, aligning access control with GCP’s security model and simplifying operational overhead. This approach is widely used to allow GKE workloads to access services like Cloud Storage, BigQuery, Secret Manager, and more—without exposing credentials inside the cluster.

‍

The Binding

Binding the KSA to a GSA involves two steps—one on the GCP IAM side, and one inside the Kubernetes cluster. This setup enables the KSA to impersonate the GSA and access Google Cloud resources securely via Workload Identity.

Grant IAM Permissions to the KSA on the GCP Side

Use the following gcloud command to grant the roles/iam.workloadIdentityUser role to the KSA:

gcloud iam service-accounts add-iam-policy-binding
GSA_NAME@PROJECT_ID.iam.gserviceaccount.com --
role="roles/iam.workloadIdentityUser" --member="serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]"

‍

This command allows the KSA to act as the GSA. Each parameter is defined below:

• GSA_NAME: The name of the Google Cloud Service Account being impersonated.
• PROJECT_ID: The Google Cloud project ID that owns the GSA.
• K8S_NAMESPACE: The namespace in the Kubernetes cluster where the KSA exists.
• KSA_NAME: The name of the Kubernetes Service Account to be bound.

The member string is a special identity format used by GCP to represent a Kubernetes Service Account via Workload Identity.

Annotate the KSA in Kubernetes

The Kubernetes side must explicitly declare which GSA it wants to impersonate by annotating the KSA:

‍

kubectl annotate serviceaccount KSA_NAME \ 
  --namespace K8S_NAMESPACE \ 
  iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

‍

The kubectl annotate command links the Kubernetes Service Account (KSA) to the specified Google Service Account (GSA) within the GKE Workload Identity system. Any workload that uses the annotated KSA is permitted to impersonate the GSA, provided the corresponding IAM binding exists on the Google Cloud side.

Together, these two steps complete the binding. The GSA handles access control via IAM, and the KSA provides a Kubernetes-native identity to the workload. When a pod uses the KSA, it inherits the permissions of the GSA without needing static keys—achieving secure, scalable identity federation.

Identifying KSA and GSA Binding

Workload Identity bindings between KSAs and GSAs are reflected in GCP audit logs as IAM policy updates. These logs are useful for tracking which KSAs were granted permission to impersonate a specific GSA.

Key log elements for identifying a binding event:

• methodName: The method SetIamPolicy indicates a binding was applied through a policy change.
• request.policy.bindings.members: Lists the KSA identities (formatted as serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]) being granted the roles/iam.workloadIdentityUser role.
• request.resource: Points to the target GSA that the KSAs will be allowed to impersonate.
• serviceData.policyDelta.bindingDeltas: Captures the change in the IAM policy, including the action (ADD), the member (KSA), and the role assigned (roles/iam.workloadIdentityUser).

‍

‍

‍

How does GKE Workload Identity Federation work?

The GKE Workload Identity Federation authentication process uses a Kubernetes-issued identity token, which is exchanged for a Google Cloud access token via Google's Security Token Service (STS).

‍

‍

‍

The typical authentication flow is as follows:

• Token request by the workload

  A GKE workload makes a token request using Application Default Credentials (ADC), typically to access a Google Cloud API.
• Kubernetes JWT issued

  ‍The GKE metadata server intercepts the request and asks the Kubernetes API server to issue a signed JSON Web Token (JWT) representing the Kubernetes Service Account (KSA) tied to the workload.
• JWT exchanged with STS
  ‍
The metadata server forwards the JWT to Google's STS to perform a federated token exchange.
• Federated GCP access token returned

  STS returns a short-lived federated token representing the GSA identity mapped to the KSA, based on the binding.
• Workload accesses Google Cloud
  ‍
The workload uses the federated token to access Google Cloud resources, with permissions determined by the associated GSA.

‍

Identifying GKE Workload Identity Impersonated Operations

Once GKE Workload Identity is active, the resulting logs follow the same structure as other workload identity flows. The impersonated GCP Service Account (GSA) appears in the principalEmail, while the original Kubernetes identity is captured in the serviceAccountDelegationInfo.principalSubject field.

In GKE-based workload identity, the principalSubject contains a reference formatted with svc.id.goog, which indicates that the source identity is a Kubernetes Service Account (KSA). This value also includes the namespace and service account name, making it possible to determine exactly which KSA triggered the request and from which namespace it originated.

This level of visibility is especially useful for forensic investigations. Since KSA names can be reused across namespaces, the presence of the namespace in the log allows precise identification of the source workload—even in multi-tenant or large-scale environments.

In the example shown below, the workload accessed a BigQuery resource using the GSA, but the log still provides full traceability back to the specific KSA and namespace that initiated the action.

‍

‍

Workforce Identities - Workforce Identity Federation

‍

What is Workforce Identity Federation?

Workforce Identity Federation allows human users to securely access Google Cloud resources using their existing identity from an external Identity Provider (IdP), such as EntraID, Okta, or AD FS. It enables the users to authenticate without requiring Google accounts or syncing identities into Google Cloud Identity.

This approach addresses several operational and security challenges:

• Duplicate Identity Management: Traditionally, organizations needed to sync users into GCP using Google Workspace or Cloud Identity, which added complexity and created multiple identities for the same user.
• Operational Overhead: Maintaining user directories across both the IdP and Google Cloud introduces administrative burden, increased attack surface, and risk of inconsistencies.

Instead, Workforce Identity Federation provides a streamlined, syncless model for identity management:

• Keyless, Attribute-Based Access: By federating identities using standard protocols like OpenID Connect (OIDC) or SAML 2.0, users authenticate through their existing IdP. Google Cloud validates these identity assertions and grants access based on short-lived tokens—without managing permanent Google identities.
• Centralized Policy Enforcement: Permissions are assigned in Google Cloud using IAM roles and attribute mappings defined in Workforce Identity Pools, allowing secure access control without identity duplication.

How Does Workforce Identity Federation Work?
‍

‍

The authentication process follows a standard token exchange pattern:

1. User initiates login

   A user attempts to access a GCP resource via the console, gcloud, or a third-party app.
2. Redirection to Identity
   ‍ Provider
The user is redirected to the configured external IdP (e.g., Entra ID, Okta) for authentication.
3. Token issued by IdP
   ‍
After successful authentication, the IdP returns a signed identity token (JWT or SAML assertion) containing user claims.
4. Token exchange with STS

   The identity token is sent to Google Cloud's Security Token Service (STS), which validates the token and issues a short-lived Google Cloud access token.
5. Access granted
   ‍
The access token is used to access GCP resources. IAM roles are granted based on mapped identity attributes.

The mapping of identity attributes to permissions is handled by a Workforce Identity Pool, which defines the relationship between external identities and GCP IAM principals. Each pool includes configured identity providers and determines how users from those providers are authorized to act within GCP.

Identifying Workforce Identity Operations

When a federated user accesses Google Cloud using Workforce Identity Federation, their identity appears in audit logs in the principalSubject field of authenticationInfo.

This field includes a structured identity string indicating the workforce pool, and the external subject (usually an email or unique username). This log pattern provides attribution of actions performed by federated users and helps distinguish workforce identities from internal service accounts or workloads—making it essential for audits and investigations.

In the example shown below, the log identifies that the action was performed by an external user via Workforce Identity Federation, showing both the workforce pool and the user identity.

‍

Summary

Understanding key identity types beyond regular service accounts—Service Agents, Workload Identities, GKE Workload Identity Federation, and Workforce Identities—and how each appears in GCP audit logs is essential during investigations, as they represent the actors behind many critical operations. Knowing how to trace them in logs enables accurate attribution, threat detection, and response. By identifying where access originated—whether from a federated workload, a CI pipeline, or a specific namespace—investigators can reconstruct timelines, understand impact, and link activity to its true source.

Ultimately, GCP’s audit logs provide the clarity and structure needed to answer the question at the heart of every investigation: Who touched my GCP project?