An enterprise organization is deploying Workload Identity Federation across multiple external continuous integration (CI/CD) platforms to access Google Cloud resources securely. The security team needs to establish a comprehensive security and auditing baseline for the federation lifecycle. The implementation must satisfy two primary requirements: Maintain a complete, non-repudiable audit trail that links external identity claims to specific Google Cloud API actions, even for services that do not natively log impersonation metadata. Protect the credential exchange process against identity spoofing and privilege escalation caused by unauthorized configuration changes or mutable external claims. Which configuration strategy should the security engineer implement?

Enable Data Access audit logs for the Security Token Service API and IAM API across workload identity pool projects, restrict the IAM Workload Identity Pool Admin role to a dedicated management project, and map only immutable, authoritative provider claims.: ### What this solution is This strategy establishes an end-to-end security architecture for **Workload Identity Federation (WIF)** by combining deep audit logging with strict administrative boundaries and immutable claim mappings. ### How it meets the audit trail requirement - **Security Token Service (STS) Data Access Logs**: When an external workload exchanges an external token (such as an OIDC JWT or SAML assertion) for a federated token, the exchange is executed against the **Security Token Service API** (`sts.googleapis.com`). Enabling **Data Access audit logs** ensures that every token exchange event—along with its mapped external attributes—is permanently captured. - **IAM Data Access Logs**: Impersonation events against service accounts via `GenerateAccessToken` are recorded in **Identity and Access Management (IAM) API** Data Access logs, providing an unbroken audit trail back to the originating external identity even when downstream resource APIs do not natively populate `serviceAccountDelegationInfo`. ### How it meets the security and anti-spoofing requirement - **Dedicated Management Project**: Managing workload identity pools in a dedicated project isolates the `roles/iam.workloadIdentityPoolAdmin` role, preventing unauthorized actors from inheriting `iam.googleapis.com/workloadIdentityPoolProviders.update` permissions from parent folders. - **Restricting Attribute Updates**: Preventing unauthorized modifications to **attribute mappings** prevents attackers from altering mapping rules to grant themselves unauthorized service account access. - **Authoritative Claim Mapping**: Mapping only immutable attributes (such as an internal unique user or repository ID) ensures that mutable attributes like usernames or email addresses cannot be spoofed in external systems. ### Key advantages - **Non-repudiation**: Complete correlation between external CI/CD workload executions and Google Cloud operations. - **Least privilege administration**: Prevents privilege escalation through compromised provider configurations. - **Spoofing resistance**: Eliminates risks associated with recycled or modified external usernames.

Workload Identity Federation Audit And Security Controls | Professional Cloud Security Engineer

Workload Identity Federation Audit And Security Controls

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

An enterprise organization is deploying Workload Identity Federation across multiple external continuous integration (CI/CD) platforms to access Google Cloud resources securely. The security team needs to establish a comprehensive security and auditing baseline for the federation lifecycle.

The implementation must satisfy two primary requirements:

Maintain a complete, non-repudiable audit trail that links external identity claims to specific Google Cloud API actions, even for services that do not natively log impersonation metadata.
Protect the credential exchange process against identity spoofing and privilege escalation caused by unauthorized configuration changes or mutable external claims.

Which configuration strategy should the security engineer implement?

Rely on standard Admin Activity audit logs for IAM, configure workforce identity pool session lengths to 15 minutes, and map the external subject claim directly to user email addresses.

Create service account keys for each CI/CD runner, store them in a HashiCorp Vault cluster, and deploy Cloud Functions to revoke and rotate the JSON keys on an hourly schedule.

Assign the Owner role on workload identity pool providers to developers, map the external subject to the issuer URL, and configure Cloud Storage Bucket Lock on audit sinks.

Enable Data Access audit logs for the Security Token Service API and IAM API across workload identity pool projects, restrict the IAM Workload Identity Pool Admin role to a dedicated management project, and map only immutable, authoritative provider claims.

Professional Cloud Security Engineer

Workload Identity Federation Audit And Security Controls

Related questions