Managing Cloud Identity for Google Cloud

1.1GCDS Architecture and Synchronization Rules

Google Cloud Directory Sync (GCDS) (opens in a new tab) is a provisioning bridge that copies users and groups from on-premises Active Directory to Cloud Identity or Google Workspace without copying passwords. Data flows from Active Directory to the GCDS host over Lightweight Directory Access Protocol (LDAP), then from the GCDS host to Google over HTTPS to the Directory API and Domain Shared Contacts API. Because the Google APIs are publicly reachable, traffic from GCDS to Google needs little firewall change, while traffic from GCDS to Active Directory requires direct LDAP network access.

The GCDS host should run on a separate Windows or Linux machine with LDAP access to Active Directory, not on a domain controller. Configuration is managed in Configuration Manager, which writes an XML file containing an OAuth refresh token for Google authentication. That file must be stored in a restricted folder such as $Env:ProgramData\gcds because anyone with the token can authenticate to Google as the sync account. Communication to Active Directory uses unencrypted LDAP by default, so remote queries should use LDAPS or Cloud VPN for encryption.

GCDS depends on two dedicated service identities on opposite sides of the sync boundary. On the Active Directory side, GCDS authenticates with a dedicated domain user such as gcds, created with password never expires and change-at-next-logon cleared. On the Google side, GCDS authenticates as a dedicated Cloud Identity user such as cloud-directory-sync that holds the Super Admin role. That Google account should use a manually set password, 2-step verification, and exemption from single sign-on (SSO) (opens in a new tab) so SSO failure does not block re-authorization.

Attribute mapping controls how an Active Directory object becomes a Google user. GCDS populates Given Name from LDAP givenName and Family Name from sn, while the Email Address Attribute decides which source value becomes the Google primary email. Choose userPrincipalName mapping when UPN suffixes already match verified Google domains, enable domain substitution when internal UPN suffixes must be replaced with the public Google domain, and choose mail-attribute mapping when the mail attribute is authoritative. The proxyAddresses attribute can be synced to preserve aliases when aliases should be provisioned.

Filtering rules control which objects GCDS may provision. Scope is set by selecting User Accounts and Groups while leaving Organizational Units, User Profiles, and Custom Schemas unselected when only users and groups are needed. The standard user LDAP search rule matches only active person accounts and excludes the sync account, with Scope set to Sub-tree and Base DN left blank to search the whole forest. Leaving Base DN blank searches all domains, while entering a DN limits searches to that subtree.

1.2SAML SSO Flow and Trust Configuration

Single sign-on (opens in a new tab) with a third-party identity provider (IdP) lets users authenticate at the external IdP and then access Google without a separate Google password. For Cloud Identity and Google Workspace, Google acts as the SAML service provider and the external IdP such as Active Directory Federation Services (AD FS) acts as the SAML IdP using SAML 2.0 HTTP POST binding. GCDS does not synchronize passwords, so SSO succeeds only when the user exists in Cloud Identity and has a matching identity in the external IdP.

The ordered Cloud Identity SSO flow moves the browser between Google and the IdP:

1. User request: Browser requests the Google Cloud console or another Google resource that requires authentication.
2. Redirect to Google Sign-In: Console redirects the unauthenticated browser to Google Sign-In, which prompts for an email address.
3. Account lookup: Google Sign-In looks up the Cloud Identity or Google Workspace account for that email.
4. Redirect to external IdP: Google Sign-In redirects the browser to the external IdP sign-in URL with RelayState and SAMLRequest parameters.
5. Authentication at IdP: External IdP authenticates the user, enforces its own policies and multi-factor authentication (MFA), and builds a SAML assertion for audience google.com, or google.com/a/DOMAIN when domain-specific issuer is used.
6. POST to ACS: Browser posts the assertion to the assertion consumer service (ACS) URL containing the primary domain, such as https://www.google.com/a/example.com/acs.

Trust requires matching identifiers on both sides. The SAML profile in the Admin console holds the IdP entity ID, sign-in URL, sign-out URL, password-change URL, and verification certificate, while the AD FS relying party trust holds the Google Entity ID and ACS URL copied from that profile. The AD FS trust must be Claims aware, must enable SAML 2.0 WebSSO with the correct ACS URL, and must list the Google Entity ID as a relying party identifier. Workforce Identity Federation (opens in a new tab) uses a related Service Provider Initiated flow where Google looks up IdP information in a workforce identity pool before redirecting to the third-party IdP.

Workforce Identity Federation also controls access to workload interfaces such as Component Gateway. Managed Service for Apache Spark runs component web interfaces on the first master node of a cluster, and federated users reach them through a dedicated URL of the form https://UNIQUE_ID-dot-dataproc.byoid.googleusercontent.com. Access depends on three prerequisites in order: configure federation in the project, grant the external identity dataproc.clusters.use, and create the cluster with Component Gateway enabled. If the user is not signed in, Google redirects first to the authentication portal for the workforce pool provider name, then to the external IdP, then back to the interface.

Service account impersonation is often combined with federation to limit privilege. Impersonation always involves two identities: the authenticated principal who initiates the request and the service account that is impersonated. The principal obtains a short-lived token with the gcloud --impersonate-service-account flag, with the Service Account Credentials API, or with a Workload Identity Federation credential configuration file, then authenticates as the service account. Use of a service account key or an attached service account is not impersonation because only the service account identity is involved.

1.3Diagnosing GCDS Provisioning and SSO Failures

GCDS logging and simulation separate mapping errors from connection and authorization errors. GCDS writes a timestamped log such as PROGRAM_DATA\gcds\gcds_sync.#{timestamp}.log and can send email notifications through a configured mail server. Simulation reports proposed changes without modifying Cloud Identity, while Sync and apply changes permanently creates, updates, suspends, or deletes users and groups.

The operational lifecycle runs in order: configure logging, select Clear cache and run Simulate sync, then select Clear cache and run Sync and apply changes for initial provisioning, then schedule hourly sync with sync.ps1. Always select Clear cache before either mode so results reflect current Active Directory data. For large directories, narrow the LDAP search rule to a small pilot subset first, because repeated bulk deletes can be flagged as abusive behavior.

Most failures after successful connection are attribute or scope errors:

• Email mismatch where Email Address Attribute uses userPrincipalName in one environment and mail in another, or domain substitution is enabled without replacing LDAP domains with the Google domain.
• Name gaps where Given Name and Family Name are not populated from givenName and sn, or alias sync is left enabled when aliases should not be provisioned.
• Scope errors where the LDAP rule does not exclude disabled accounts, computer objects, managed service accounts, and the gcds account itself.
• Duplicate conflicts reported as HTTP 409 Conflict for duplicate google.subject, google.group, userName, or displayName values.
• Silent delays where group membership or sharing fails because System for Cross-domain Identity Management (SCIM) claim mapping is inconsistent or SCIM is not enabled for groups.

Certificate, entity ID, and claim failures break SSO trust after provisioning succeeds. An expired verification certificate breaks signature validation, so upload the current IdP signing certificate before expiration. An incorrect entity ID or ACS URL breaks routing and can appear as a missing IdP login screen or Verification failure: missing session ID in request. Claim failures include mismatched NameID or email attributes, JSON Web Tokens (JWTs) larger than 4KB when too many groups are sent, and HTTP 403 when IDP group mapping still points to the old provider after changing IdPs. To reduce token size, filter the groups claim to only groups needed for Google SecOps.

2.1Super Administrator and Organization Administrator Responsibilities

Super administrator accounts (opens in a new tab) control the Cloud Identity or Google Workspace domain and the lifecycle of the Google Cloud organization resource. A super administrator can assign the Organization Administrator role, recover domain accounts, and control account and organization lifecycle including deletion. The super administrator that creates the organization is automatically assigned the Organization Administrator role and serves as the recovery contact.

The Organization Administrator controls daily cloud resource administration inside the organization resource (opens in a new tab). That role defines allow and deny policies, grants Identity and Access Management (IAM) roles, and views the resource hierarchy, but it cannot create folders or projects without additional roles. Separation of duties keeps emergency identity control with the super admin and routine resource control with the Organization Administrator.

The recommended delegation pattern creates a private administrator group, adds Organization Administrator users to that group but not the super admin user, and grants the group the Organization Administrator role or a limited subset. Permissions flow downward by inheritance from organization to folders to projects, so removing a user from the privileged group immediately removes inherited access to child resources.

2.2Provisioning Sources and Redundant Administrator Groups

Secure provisioning starts by choosing the identity source of truth where users, passwords, and MFA are managed. Google Workspace or Cloud Identity can provision users directly in the verified domain, an external provider such as Microsoft Entra ID or Okta can connect through Workforce Identity Federation with a workforce pool and provider ID, or Google accounts can be created now with federation added later. Before creating managed accounts, existing unmanaged Google Accounts must be found and migrated to corporate credentials.

Connecting an external provider follows a fixed order: create a globally unique workforce pool ID and provider ID, complete provider-side configuration so the provider trusts Google Cloud, add the provider as a trusted authority in Google Cloud, connect provider groups to Google Cloud administrative functions, and assign more than one user to each group. Data flows from the external provider to the workforce pool at authentication time, then from group membership to IAM policies at authorization time.

Administrative groups are the only scalable principal for privileged access. IAM roles are assigned to group emails such as gcp-billing-admins@example.com, and users gain or lose access by joining or leaving the group. Roles must not be assigned to individual users because individual grants bypass job-based review and are hard to audit.

• gcp-organization-admins administers all organization resources and is reserved for the most trusted users.
• gcp-billing-admins sets up billing accounts and monitors usage.
• gcp-network-admins creates Virtual Private Cloud networks, subnets, and firewall rules.
• gcp-hybrid-connectivity-admins creates Cloud VPN, Cloud Router, and related connectivity.
• gcp-security-admins sets organization security, access management, and constraint policies.
• gcp-logging-monitoring-admins and gcp-logging-monitoring-viewers separate full logging administration from read-only viewing.

Redundancy is required at provisioning time. Organizations must maintain more than one super administrator and more than one Organization Administrator, with up to 20 backup administrator accounts supported. A single super administrator creates lockout risk and allows unchecked platform-altering changes.

2.3Authentication, Session, and Recovery Controls for Super Admins

Phishing-resistant authentication for super admins requires mandatory MFA with dedicated hardware security keys. Super admins bypass organization SSO and authenticate directly to Cloud Identity by design, which preserves access during an SSO outage but removes external IdP controls from the highest-value accounts. Enforcement inside Cloud Identity is therefore critical even when MFA is already enforced at the external provider.

Robust sign-in controls for these accounts work as peer protections:

• Enforce MFA on all super admin and highly privileged accounts.
• Require a physical security key for 2-step verification, such as Titan Security Keys or other FIDO U2F keys, and store the initial key in a safe location.
• Give each super admin a separate dedicated login such as alice-admin@example.com separate from alice@example.com, and apply the same suspension policy in Cloud Identity and any synced identity.
• Enforce a short sign-in period where available, a 15-minute idle timeout for sensitive use, and reauthentication every 16 hours for Google Cloud services using a security key.
• Enable post-SSO verification so Google risk analysis can challenge suspicious sign-ins.

Session exposure is reduced by discouraging routine use of super admin accounts, capping maximum web session length, aligning Google session length with SSO provider controls, and avoiding broad basic roles such as Owner, Editor, or Viewer. Persistent OAuth tokens and persistent web sessions create theft risk if exposed on workstations. Least-privilege assignment avoids overly permissive grants that enable privilege escalation and lateral movement.

Recovery depends on peer assistance rather than self-service. Self-recovery through a compromised phone, email, or social engineering attack can hand an attacker full control, so self-recovery must be disabled for super admins. Self-recovery is off by default for new customers but may still be on for existing customers, so settings must be verified in the Admin console. The compensating process is that a locked-out super admin contacts another super admin, with support-assisted recovery as the fallback.

2.4Auditing Privilege Changes and Lifecycle Reviews

Accountability for privileged access depends on centralized logging and periodic access reviews. Google Cloud Observability (opens in a new tab) alerts when a SetIamPolicy() API call modifies an allow policy, so every privilege grant sends a notification for investigation. Admin Activity audit logs from Google Workspace or Cloud Identity, including user login events, are shared into the Google Cloud environment to centralize login and policy-change signals.

Time-bound and least-privilege controls further contain privileged operations. Privileged Access Manager provides just-in-time access only when needed, group membership can expire automatically with renewal by approval workflow, and predefined roles are preferred over custom roles to reduce sprawl. Principal access boundary policies limit what a principal can access even if its identity is compromised, while Context-Aware Access can restrict console access by identity, location, device security status, and IP address.

Ongoing reviews verify Organization Administrator assignments, confirm at least one user retains the role to avoid orphaned administration, and remove users whose jobs no longer need privilege. Logs should be exported to a sink for long-term storage and analysis, including export to BigQuery, with Essential Contacts configured for critical alerts. Decommissioning removes the user from privileged groups and revokes shared credentials, which immediately removes inherited access to child folders and projects.

3.1Automated Provisioning and Deprovisioning Workflows

Automated provisioning and deprovisioning workflows synchronize user creation, group membership, and resource access from an authoritative source and remove access promptly when roles change. In Google Cloud, Cloud Identity (opens in a new tab) acts as the identity control plane, IAM acts as the authorization control plane, and Google Groups bind the two together. When a join, move, or leave event occurs, group membership changes flow into IAM allow policies so access is granted, adjusted, or revoked without editing individual bindings.

Connecting an external IdP follows an ordered setup: create a workforce pool with a globally unique pool ID and provider ID, configure Google Cloud in the provider so it trusts Google as a relying party, enter provider details in Google Cloud, map provider groups to administrative functions, and assign more than one user to each group. Because IAM evaluates the federated identity and its mapped attributes, suspension in the external IdP cuts off Google access only when suspension events propagate through the federation configuration.

Group-based role-based access control makes join-move-leave automation work. IAM roles are assigned once to groups according to job role, and users gain or lose permissions only by entering or leaving groups. A complete workflow runs in order: provision the account, add the user to role-aligned groups, move the user between groups when the job changes, then suspend at departure to block authentication immediately and delete after retention needs end.

Deprovisioning must link secondary credentials to the primary identity lifecycle. OS Login links VM SSH keys to the Google identity so VM access ends when the account is removed, while Cloud SQL Auth proxy and AlloyDB Auth proxy link database access to the Google identity. The iam.allowedPolicyMemberDomains organization constraint prevents external consumer accounts that the organization cannot suspend from receiving project access.

3.2Access Reviews, Justification, and Policy Enforcement

Continuous access reviews verify that every identity holds only the access it still needs and automatically remove violating access. Administrators apply Policy Intelligence role recommendations to replace broad grants with tighter roles, and organization constraints constraints/iam.disableServiceAccountKeyCreation and constraints/iam.disableServiceAccountKeyUpload block long-lived service account keys to force short-lived alternatives. Because key material can be copied into CLI configuration files, filesystems, or repositories, disabling keys reduces standing access that reviews must later clean up.

Automated privilege escalation separates the standing identity from the privileged capability with a group that may impersonate a privileged service account. In the documented pattern, an administrator creates a group and service account both named elevated-compute-access, grants roles/compute.admin to the service account, grants roles/serviceusage.serviceUsageConsumer on the project to the group, and grants roles/iam.serviceAccountTokenCreator on the service account to the group. Traffic flows from the user identity to service account impersonation and then to Compute Engine APIs. Membership becomes the approval boundary, with time-bound membership or periodic recertification controlling expiration.

Activity analysis compares privileged use against approved policy. Administrators enable ADMIN_READ, DATA_READ, and DATA_WRITE audit logs for services such as compute.googleapis.com, then review who impersonated privileged service accounts and what resources were touched. Log data flows from Google Cloud APIs to Cloud Audit Logs storage, with export to long-term storage for audit evidence. At enterprise scale, IAM recommender findings flow through BigQuery Data Transfer Service into BigQuery, where a query for recommender = "google.iam.policy.Recommender" and recommender_subtype = "REMOVE_ROLE" returns candidates for rightsizing.

Request-time enforcement adds context checks on every API request. Chrome Enterprise Premium evaluates user-centric conditions such as IP-based access or certificate-based mutual TLS and rejects user API traffic that fails conditions even when the credential is valid. VPC Service Controls defines resource-centric perimeters within which resources can communicate.

OS Login with 2-Step Verification enforces reauthentication for SSH to Compute Engine, blocking an attacker with stolen OAuth tokens but no second factor. RDP to Windows does not support OS Login, so administrators must use coarse controls such as session length and Identity-Aware Proxy Desktop paths.

3.3Lifecycle Monitoring, Anomaly Detection, and Remediation

Centralized audit logging aggregates administrator activity, data access, and login events so provisioning and deprovisioning can be reconstructed. Cloud Audit Logs captures IAM policy changes, service account creation and deletion, and token generation, while Workspace and Cloud Identity login logs track interactive authentication when exported to Cloud Logging. Token-generation methods such as GenerateAccessToken, GenerateIdToken, and SignJwt appear only when Data Access logs are enabled, while impersonation is traced through serviceAccountDelegationInfo.firstPartyPrincipal.principalEmail.

Security Command Center ingests asset inventory, audit logs, and threat telemetry to surface lifecycle anomalies as findings. Its Event Threat Detection source flags persistence, privilege escalation, evasion, and initial access techniques that often follow incomplete deprovisioning. Findings can flow to a security information and event management (SIEM) system or Google Security Operations for correlation and response.

Monitored findings include New Geography, New User Agent, and New API Method for unusual persistence, Access from Anonymizing Proxy for evasion, Anomalous Impersonation and Anomalous Impersonator for privilege escalation, and Leaked Service Account Key Used, Service Account Key Created, Suspicious Login Blocked, and Account Disabled Hijacked for compromised or orphaned credentials. When a finding fires, the security operations center must have pre-granted access across both the Google Cloud console and the Admin console, or investigation will be delayed.

Automated remediation revokes sessions and deletes secrets so a failed review immediately removes access. A prepared Admin SDK script can invalidate gcloud CLI OAuth tokens for client ID 32555940559.apps.googleusercontent.com and force reauthentication, while Application Default Credentials are revoked by deleting application_default_credentials.json and recreating credentials, and exposed API keys are regenerated by the API Keys Admin. Emergency access accounts remain intentionally exempt from this automation: they are created directly in Cloud Identity, hold super admin privilege, are exempt from joiner-mover-leaver automation and SSO, and are isolated in a dedicated organizational unit. Maintain two to five emergency users per account, each with 2-step verification allowing only FIDO security keys and with two or more keys enrolled per user.

4.1Programmatic User Lifecycle Through Groups

Programmatic user lifecycle management automates creating, updating, suspending, and deleting accounts as people join, move within, and leave the organization. Cloud Identity (opens in a new tab) manages users, Google Groups carry access, and IAM enforces permissions on resources. Access stays consistent because changes to group membership, not manual edits to policies, determine who can do what.

The authoritative identity source is the system where suspension and deletion must originate so Google Cloud access follows automatically. With Cloud Identity or Google Workspace management, users authenticate with managed Google accounts and receive access through group membership. With an external provider using Workforce Identity Federation, users are managed in Microsoft Entra ID, Okta, or another OIDC or SAML provider and sign in with their existing external account through a workforce identity pool, with no second Google account.

A complete group-based workflow runs in order:

1. Provision: Create a managed user in Cloud Identity or synchronize the external identity with GCDS.
2. Assign: Add the user to role-aligned groups such as billing, network, or security administration that already carry IAM roles.
3. Move: Move the user from the old group to the new group when the job changes, which revokes old permissions and grants new ones in one action.
4. Suspend and delete: Suspend at departure to block authentication immediately, then delete and remove group membership after retention ends.

Data flows from the HR system or identity provider to Cloud Identity, from Cloud Identity to group membership, and from group membership to IAM allow policies on organizations, folders, and projects.

Consistent access control means IAM roles are granted to groups according to job role, never to individual users. IAM evaluates the group as the principal, so every member inherits the same permissions and removal removes all of those permissions at once. Foundational groups include gcp-organization-admins, gcp-billing-admins, gcp-network-admins, gcp-security-admins, gcp-developers, and gcp-devops, each bound with least-privilege roles at the organization level. Each critical group should contain more than one user to avoid single-person dependency.

Suspension only works when dependent sessions and keys are also revoked. OS Login links VM SSH authorized keys to the Google identity so removing the user revokes VM access instead of leaving metadata-based keys behind. Authentication proxies for Cloud SQL and AlloyDB link database credentials to the Google identity so suspension revokes database access. The iam.allowedPolicyMemberDomains constraint restricts identities by domain to block external consumer accounts.

4.2Auditing Programmatic Changes and Group Membership

Auditing programmatic changes creates a verifiable record of every lifecycle event and proves that access still follows policy. Cloud Audit Logs records who did what, where, and when for IAM and service account operations, while Workspace Activity logs record Google group membership changes. Long-term retention through log sinks, real-time alerting in Cloud Logging, and periodic review with Policy Analyzer turn raw events into security monitoring and compliance evidence.

Cloud Audit Logs classifies logs into Admin Activity, Data Access, System Event, and Policy Denied categories. For identity administration, Admin Activity and Policy Denied logs are recommended.

Admin Activity logs are always written and cannot be configured, excluded, or disabled, even if the Cloud Logging API is disabled. That guarantee makes them the authoritative source for programmatic IAM changes, while Policy Denied logs show attempts that policy blocked.

Cloud Logging retains each log only for its default retention period, so organizations must export logs before they expire. A log sink routes copies from Cloud Logging to BigQuery or another destination for long-term storage, where analysts can select columns, view data over time, and run aggregate access analytics. Without a sink, forensics and compliance reporting are limited to the default window.

A Logs Explorer query isolates high-risk writes by filtering on log name, resource type, and method. To view IAM policy changes for a project, open Logs Explorer, set logName to projects/<PROJECT>/logs/cloudaudit.googleapis.com%2Factivity, require resource.type of project or service_account with the matching project ID, and require protoPayload.methodName equal to SetIamPolicy, google.iam.admin.v1.CreateServiceAccount, or google.iam.admin.v1.CreateServiceAccountKey. The same entries can be listed through the Cloud Logging API or gcloud CLI for repeatable evidence collection.

Changes to Google group membership are tracked in Workspace Activity logs rather than in IAM policy audit entries. Because an IAM role granted to a group applies to every current member, adding or removing a member immediately changes effective access without editing the IAM policy. Monitoring group logs is therefore required when policies are assigned to groups, including controls to ensure non-corporate accounts are not added.

4.3Automating Membership and Least-Privilege Enforcement

Google Groups (opens in a new tab) managed by Cloud Identity provide the enforcement point for role-based access control and least privilege. Administrators grant IAM roles once to the group at the organization, folder, or project level, and users gain or lose permissions only when added to or removed from the group. The trust boundary sits between group management and resource policy: group owners control who is in the group, while IAM controls what the group can do. A member inherits all IAM roles granted to the group regardless of their Groups role as owner, manager, or member.

The identity source determines where users are created and how changes propagate. With Google Workspace or Cloud Identity management, a super administrator creates users and groups that authenticate with managed accounts. With federation, users are created in the external IdP and mapped through a workforce identity pool, using either GCDS synchronization where each user has both an external and a Google account or Workforce Identity Federation where each user keeps only the external account.

Connecting an external provider follows an ordered setup: create a workforce identity pool with a globally unique pool ID and provider ID, complete provider-side OIDC or SAML configuration, register the provider details in Google Cloud as a trusted authority, map provider groups to administrative functions, and add more than one user to each critical group. Only after pool, provider trust, and group mapping exist does sign-in and role inheritance work end to end.

Least-privilege assignment gives each administrative group only the minimum IAM roles (opens in a new tab) needed for its function, granted by a super administrator or Organization Administrator. Default assignments can be customized by adding roles, removing roles, or deleting unused groups. Deleting a group is irreversible and immediately removes its inheritance path, so all IAM roles must first be revoked and deletion delayed at least 7 days to catch unexpected changes.

Automated membership still requires governance to remove orphaned accounts and unused permissions. Policy Intelligence with IAM recommender uses machine learning to identify unneeded bindings, including REMOVE_ROLE recommendations and insights about unused permissions and abandoned service accounts. At enterprise scale, recommendations are exported to BigQuery and queried for recommender = "google.iam.policy.Recommender" to rightsize bindings. Cloud Logging records lifecycle events, Workspace audit logs for user creation and group changes appear in Cloud Logging when data sharing is enabled, and Policy Analyzer verifies on a periodic basis which users can access which resources in what capacity.

5.1Workforce Pools, Providers, and IAM Access

Workforce Identity Federation (opens in a new tab) gives workforce users access without synchronizing their identities into Google Cloud. A workforce pool holds the trust configuration for an organization, and each provider inside the pool connects one external OIDC or SAML identity system to Google Cloud. Employees, partners, and contractors authenticate with their home provider, and Google Cloud authorizes them through IAM policies without creating Google Accounts for them.

Workforce principal identifiers are IAM member strings that address federated users by pool, subject, group, or attribute. Identifiers starting with principal:// address exactly one identity, while identifiers starting with principalSet:// address a group, attribute value, or whole pool.

The subject value comes from the mapped google.subject attribute, while group and attribute values come from IdP claims mapped to google.groups or custom attributes. Because pools are configured at the organization level with a globally unique pool ID, the same identifier can be referenced by allow policies in any project or folder inside that organization.

Constructing IAM bindings means choosing the narrowest principal set that still covers the workforce that needs the role. A binding to the whole-pool /* set grants the role to every identity that can authenticate through the pool and fits only broadly shared access. A binding to group/GROUP_ID or attribute.NAME/VALUE limits the role to matching group membership or mapped attributes for least privilege. A binding to a single subject/ principal addresses one user for break-glass access, delegation, or testing. Separate pools for employees, partners, or divisions isolate ownership, such as granting roles/iam.workforcePoolEditor on a partner pool to a partner administrator without giving control over employee access.

Granting access to a workload interface follows the same binding principle. For Managed Service for Apache Spark Component Gateway, federation must be configured in the project, external users must be granted dataproc.clusters.use, and the cluster must be created with Component Gateway enabled. Federated access covers most console, CLI, and API features but excludes Managed Service for Apache Spark on GKE, Personal Authentication, Service Account Based Secure Multi-tenancy, and the Output and Recommended Alerts console sections.

5.2Attribute Mappings, Conditions, and Validation

Attribute mappings translate claims from an OIDC ID token or SAML assertion into Google attributes using Common Expression Language (CEL). Each mapping pairs a Google-side key on the left with a CEL expression over the IdP assertion on the right, such as google.subject=assertion.oid. For OIDC, a top-level claim is referenced as assertion.PROPERTY_NAME, while SAML attributes often require indexing such as assertion.attributes['department'][0]. Total mappings per provider are limited to 16 KB, and sign-in fails if mappings exceed that limit. With authorization code flow, tokens travel in a backend transaction and can carry more claims than with implicit flow, where the ID token returns through the browser subject to URL size limits.

Reserved Google attributes are the standard targets produced by Security Token Service during token exchange. google.subject is the required unique identifier recorded as the principal in audit logs and used in IAM policies. google.groups carries group memberships, google.display_name sets the console display name, and google.profile_photo sets the console picture. Custom attributes with prefix attribute. carry department, cost center, or other values for fine-grained decisions.

Group mapping needs extra care because every member of a mapped group inherits any IAM grant on that group. Group names should be limited to about 40 characters, the assertion should include only groups used for federation to stay under the 400-group failure threshold, and only authorized IdP administrators should change membership of mapped groups. The google.subject value should not be an email or other mutable value, because changing it causes the user to lose access to their prior principal.

Attribute conditions are CEL boolean expressions that gate sign-in before Google issues federated tokens. The condition evaluates raw assertion fields and mapped values, and sign-in is blocked when the result is false. Examples include assertion.role == 'gcp-users' for role restriction, domain suffix checks for email restriction, and IP prefix checks for network context. Conditions also prevent the confused deputy problem by rejecting credentials intended for another platform and are mandatory for multi-tenant IdPs sharing one issuer URL, where the condition must check a tenant-specific claim such as organization or tenant ID.

Validation in the console tests a real token without completing sign-in. The workflow runs in order: allow the pool provider callback URL in the IdP redirect URIs, open the workforce pool, open the IdP provider, click Debug IdP token, sign in as a test user, and inspect mapped attributes and the boolean condition result. If a mapping or condition is wrong, edit the CEL and choose Save and refetch token to test with a fresh assertion.

5.3Federated Sessions, Token Exchange, and Trust Boundaries

Session duration is the pool-level lifetime that controls how long federated access remains valid before re-authentication. The same duration applies to Google Cloud access tokens obtained through token exchange, console federated sign-in sessions through auth.cloud.google, and gcloud CLI sessions. Duration defaults to one hour (3600s) and must be between 15 minutes (900s) and 12 hours (43200s), set with --session-duration at pool creation and changeable later. Shorter duration reduces exposure from stolen tokens and stale group membership at the cost of more frequent sign-ins.

The token flow follows OAuth 2.0 Token Exchange, where a credential flows from the external IdP to Security Token Service, the service verifies the identity, and the service returns a short-lived Google Cloud access token. For browser access, the user signs in through console federated sign-in at auth.cloud.google using the provider resource name locations/global/workforcePools/POOL_ID/providers/PROVIDER_ID. For programmatic access, the gcloud CLI exchanges an IdP token using a credential configuration file that points to https://sts.googleapis.com/v1/token.

The gcloud lifecycle proceeds in order: save the OIDC ID token or SAML response to a local file, run gcloud iam workforce-pools create-cred-config with the pool provider audience, subject token type, token URL, and workforce pools user project, then run gcloud auth login --cred-file=config.json so gcloud transparently exchanges the IdP credential for temporary access tokens. The workforce pools user project identifies the application to Google APIs and serves as the default quota project, and the principal needs serviceusage.services.use on that project because some APIs bill and enforce quota against the client project.

The organization trust boundary defines where pool principals can directly act. Workforce pool principals cannot directly access resources outside the organization that owns the pool, so a pool in one organization does not grant access in another. That boundary depends on direct resource access, because IAM policies for those principals are evaluated inside the owning organization. The boundary can be bypassed if a workforce principal may impersonate a service account inside the organization, since service accounts are not equally restricted. To contain that risk, grant impersonation only to narrowly scoped group or attribute sets, audit pool membership through Cloud Audit Logs by pool ID, and use separate pools to contain blast radius by workforce.

Key Facts

• Google Cloud Directory Sync copies users and groups from Active Directory to Cloud Identity over LDAP and HTTPS without synchronizing passwords, and validation must run Simulate sync with Clear cache before Sync and apply changes.
• Super administrators bypass organization SSO and authenticate directly to Cloud Identity, so they require 2-step verification with phishing-resistant security keys and disabled self-recovery with peer-assisted recovery.
• IAM roles are granted to Google Groups by job role rather than to individual users, so adding or removing group membership grants and revokes access everywhere the group is used.
• Workforce principal identifiers use principal:// for exactly one federated subject and principalSet:// for a group, an attribute value, or the whole pool with /*, with session duration defaulting to one hour and constrained between 15 minutes and 12 hours.
• Admin Activity audit logs are always written and cannot be disabled, while group membership changes are recorded in Workspace Activity logs and token-generation methods require Data Access logs to be enabled.