Example logs for Workload Identity Federation Stay organized with collections Save and categorize content based on your preferences.
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 the
sub, 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_anchororintermediate_catimeUntilExpiration: the remaining time in seconds until certificateexpiration when it's used in the certificate chain verificationfingerprintSha256: 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
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
- Configure and view the audit logs for IAM.
- Get more information aboutCloud Audit Logs.
- Set upidentity federation using workloadidentity pools.
- Learn aboutservice accounts.
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.