Example logs for Workload Identity Federation

This page shows examples of the audit logs that are generated when you useWorkload Identity Federation. WithWorkload Identity Federation, you can allow an on-premises or multicloudworkload to access Google Cloud resources, without using a service account key.

Note: Each example shows only the most relevant fields in the log entries.

For more information about enabling and viewing audit logs, seeIAM audit logging.

Logs for exchanging an IdP token for a federated token

After youset up your workload identity pools andidentity provider (IdP), you can create a token for your IdP andexchange it for a federated token.

IAM can generate audit logs when principals exchange a token.To receive audit logs for all steps of the token-exchange process, you mustenable audit logs for Data Access activity for thefollowing APIs:

  • Identity and Access Management (IAM) API (enable log type "Admin Read")
  • Security Token Service API (enable log type "Admin Read")

After you enable audit logs for Data Access activity, IAMgenerates an audit log entry each time a principal exchanges a token. The logentry includes the following fields:

  • protoPayload.authenticationInfo.principalSubject: The subject of theIdP token.
    • On Amazon Web Services (AWS), this field contains the Amazon Resource Name(ARN) of the principal that you authenticated.
    • On Microsoft Azure, this field contains the object ID of the managedidentity that you specified as the Azure token subject.
    • For other OIDC IdPs, this field contains the value of thesub, or subject, claim from the OIDC token.
  • protoPayload.metadata.mapped_principal: The subject of the token, usingIAM syntax to identify the principal:

    principal://iam.googleapis.com/projects/project-number/locations/global/workloadIdentityPools/pool-id/subject/identifier
  • protoPayload.resourceName: The workload identity pool provider that thetoken is associated with.

The following example shows an audit log entry for a request to exchange atoken. In this example, a Microsoft Azure token was exchanged for a federatedtoken:

{"logName":"projects/my-project/logs/cloudaudit.googleapis.com%2Fdata_access","protoPayload":{"@type":"type.googleapis.com/google.cloud.audit.AuditLog","authenticationInfo":{"principalSubject":"b6112abb-5791-4507-adb5-7e8cc306eb2e"},"metadata":{"mapped_principal":"principal://iam.googleapis.com/projects/1234567890123/locations/global/workloadIdentityPools/azure-pool/subject/a1234bcd-5678-9012-efa3-4b5cd678ef9a"},"methodName":"google.identity.sts.v1.SecurityTokenService.ExchangeToken","resourceName":"projects/1234567890123/locations/global/workloadIdentityPools/azure-pool/providers/azure","request":{"@type":"type.googleapis.com/google.identity.sts.v1.ExchangeTokenRequest","grantType":"urn:ietf:params:oauth:grant-type:token-exchange"}},"resource":{"type":"audited_resource"}}

Logs for signed and encrypted SAML assertions

This section describes the Cloud Audit Logs log entries that Security Token Servicecreates when it attempts to verify signed SAML assertions or decrypt encryptedassertions that are sent from your IdP.

For Workload Identity Federation, the pertinent logentry looks similar to the following:

"keyInfo": [  {    "use": "verify""fingerprint": "3C:B2:47:F8:A5:9A:8A:52:BD:1C:BC:96:B5:45:C1:8D:A7:F1:73:2D"  },  {    "use": "decrypt""resourceName": "//iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_POOL_NAME/providers/PROVIDER_NAME/keys/KEY_NAME"  }]

This output includes the following values:

  • fingerprint: the hexadecimal representation of the SHA-256 hash of the X.509certificate that was used to verify the signature on the SAML credential. TheX.509 certificate is extracted from the SAML XML metadata that is attached tothe workload identity pool provider.
  • resourceName: the resource name of the workloadidentity pool provider key that was used to decrypt the encryptedSAML assertion. This field is present only if identity federation receives anencrypted SAML response from your IdP.

Logs for X.509 federation

Preview — X.509 certificate-based federation

This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of theService Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see thelaunch stage descriptions.

This section describes the Cloud Audit Logs log entries that Security Token Servicecreates when it attempts to verify mTLS client certificate with a pre-configured trust store.

For Workload Identity Federation, the pertinent logentry looks similar to the following:

"keyInfo": [  {"certificateType": "trust_anchor""timeUntilExpiration": 3333405600s"fingerprintSha256": "e33f612a0e426692f29db2c7b17b9e3810ce13f09ad117c67e7227a84fd25ea5"    "use": "verify"  }

This output includes the following values:

  • certificateType: the type of certificate involved in the client certificateverification, which can be eithertrust_anchor orintermediate_ca
  • timeUntilExpiration: the remaining time in seconds until certificateexpiration when it's used in the certificate chain verification
  • fingerprintSha256: the hexadecimal representation of the SHA-256 hash of theX.509 certificate

Logs for creating short-lived credentials for a service account

After you exchange the IdP token for a federated token, you canuse the federated token to create short-lived credentials for a service account.All Google services allow you to authenticate with these short-livedcredentials.

After you enable IAM audit logs for Data Access activity,IAM generates an audit log entry each time a principalgenerates short-lived credentials for a service account. The log entry includesthe following fields:

  • protoPayload.authenticationInfo.principalSubject: The subject of thefederated token.
  • resource.labels.email_id: The service account for which short-livedcredentials were generated.

The following example shows an audit log entry for a request to generate ashort-lived OAuth 2.0 access token for a service account. In this example, therequest was authenticated with federated credentials, and the short-livedcredentials were created for the service accountmy-service-account@my-project.iam.gserviceaccount.com:

{"logName":"projects/my-project/logs/cloudaudit.googleapis.com%2Fdata_access","protoPayload":{"@type":"type.googleapis.com/google.cloud.audit.AuditLog","authenticationInfo":{"principalSubject":"principal://iam.googleapis.com/projects/1234567890123/locations/global/workloadIdentityPools/aws-pool/subject/012345678901"},"methodName":"GenerateAccessToken","request":{"@type":"type.googleapis.com/google.iam.credentials.v1.GenerateAccessTokenRequest","name":"projects/-/serviceAccounts/my-service-account@my-project.iam.gserviceaccount.com"},"resourceName":"projects/-/serviceAccounts/123456789012345678901"},"resource":{"labels":{"email_id":"my-service-account@my-project.iam.gserviceaccount.com","project_id":"my-project","unique_id":"123456789012345678901"},"type":"service_account"}}

Logs for authenticating with credentials for the impersonated service account

After you create short-lived credentials for a service account, you can use thecredentials to impersonate the service account when you call Google CloudAPIs.

Some of the methods you call might generate audit logs. In general, theselog entries show the following identities:

  • The service account that the short-lived credentials are impersonating
  • The identity that created the short-lived credentials

Note: Some Google Cloud services, including App Engine and Google Kubernetes Engine, do not log the identity that created the short-lived credentials.

For example, suppose that the userjamie@example.com creates a federated tokenfor the subjectprincipal://iam.googleapis.com/projects/1234567890123/locations/global/workloadIdentityPools/aws-pool/subject/jamie@example.com,then uses the federated token to create short-lived credentials for the serviceaccountmy-service-account@my-project.iam.gserviceaccount.com.

The user then creates a new Pub/Sub topic, using the short-livedcredentials to impersonate the service account. Pub/Sub generatesa log entry that identifies the service account, as well as the subject of thetoken from the IdP:

{"logName":"projects/my-project/logs/cloudaudit.googleapis.com%2Factivity","protoPayload":{"@type":"type.googleapis.com/google.cloud.audit.AuditLog","authenticationInfo":{"principalEmail":"my-service-account@my-project.iam.gserviceaccount.com","serviceAccountDelegationInfo":[{"principalSubject":"principal://iam.googleapis.com/projects/1234567890123/locations/global/workloadIdentityPools/aws-pool/subject/012345678901"}]},"methodName":"google.pubsub.v1.Publisher.CreateTopic","request":{"@type":"type.googleapis.com/google.pubsub.v1.Topic","name":"projects/my-project/topics/my-topic"},"resourceName":"projects/my-project/topics/my-topic"},"resource":{"type":"pubsub_topic"}}

What's next

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-12-15 UTC.