Concept and mechanism
Workforce Identity Federation lets people from an external IdP use federated identities to access supported Google Cloud services. It does not require synchronizing each person into a Google account. Workload Identity Federation handles application and automation identities; choosing the mechanism begins with identifying who acts. In both, authentication and authorization are distinct decisions. A valid issuer signature does not authorize every repository or user. Define trusted attributes, conditions, and bounded bindings. For people, use a stable unique subject. An attribute changing with display name can break the connection to grants. Whoever manages membership of IAM-mapped groups also influences destination authorization.
Guided application
In a fictional APS intervention, an operator needs elevated access for 45 minutes. PAM can define requesters, roles, duration, and appropriate approval or justification in an entitlement. The team should test granting and expiry, including other permanent access paths. If Terraform authoritatively replaces the complete policy, it can remove bindings PAM legitimately created. Coordinate ownership and use suitable non-authoritative resources where needed. Impersonation also deserves analysis: permitting token issuance for a service account can expose that account’s privileges; short-lived tokens do not mean read-only operations. Retain identity, purpose, and scope in intervention evidence without distributing long-lived keys through tickets or email.
Expiring one grant does not revoke the same role obtained through a permanent group.
Common pitfalls
People as workloads; signature as authorization; mutable subject; Terraform as IAM’s sole writer.
Related topics: IAM, deny, and inheritance · IAP, WAF, and perimeters · Connectivity and perimeter migration
Design stable identity and temporary access without hidden permanent paths.
Reference: Workforce Identity Federation · Current linked guide; edition date unconfirmed (2026-09-30 inspection)