Example logs for workload identity federation

This page shows examples of the audit logs that are generated when you use workload identity federation. With workload identity federation, you can allow an on-premise or multi-cloud workload to access Google Cloud resources, without using a service account key.

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

Logs for exchanging an IdP token for a federated token

After you set up your workload identity pools and identity provider (IdP), you can create a token for your IdP and exchange 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 must enable audit logs for Data Access activity for the following 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, IAM generates an audit log entry each time a principal exchanges a token. The log entry includes the following fields:

  • protoPayload.authenticationInfo.principalSubject: The subject of the IdP 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 managed identity 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, using IAM 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 the token is associated with.

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

{
  "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 Service creates when it attempts to verify signed SAML assertions or decrypt encrypted assertions that are sent from your IdP.

For workload identity federation, the pertinent log entry 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.509 certificate that was used to verify the signature on the SAML credential. The X.509 certificate is extracted from the SAML XML metadata that is attached to the workload identity pool provider.
  • resourceName: the resource name of the workload identity pool provider key that was used to decrypt the encrypted SAML assertion. This field is present only if workload identity federation receives an encrypted SAML response from your IdP.

Logs for creating short-lived credentials for a service account

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

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

  • protoPayload.authenticationInfo.principalSubject: The subject of the federated token.
  • resource.labels.email_id: The service account for which short-lived credentials were generated.

The following example shows an audit log entry for a request to generate a short-lived OAuth 2.0 access token for a service account. In this example, the request was authenticated with federated credentials, and the short-lived credentials were created for the service account my-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 the credentials to impersonate the service account when you call Google Cloud APIs.

Some of the methods you call might generate audit logs. In general, these log 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 user jamie@example.com creates a federated token for the subject principal://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 service account my-service-account@my-project.iam.gserviceaccount.com.

The user then creates a new Pub/Sub topic, using the short-lived credentials to impersonate the service account. Pub/Sub generates a log entry that identifies the service account, as well as the subject of the token 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