Skip to main content

Cloud Identity

Exam guide§1.1, 4.1

Cloud Identity is where your users and groups actually live. IAM grants roles to identities, but it doesn't create them - the identities come from Cloud Identity (or Google Workspace, which includes it). The organization node in the resource hierarchy is tied one-to-one to a Cloud Identity / Workspace domain.

Users and groups

  • Users - individual people, e.g. alice@example.com.
  • Groups - named collections of users, e.g. data-team@example.com. You grant IAM roles to the group; membership changes take effect automatically.
GotchaAlways grant to groups, not individuals

Best-practice questions want roles granted to groups. When someone joins or leaves a team you change group membership in one place instead of editing IAM policy on every project. Any answer that grants a role directly to a personal email is the wrong one in a "manageable at scale" scenario.

Provisioning at scale (manual vs automated)

WayWhen
Manually in the Admin consoleA handful of users
Bulk CSV uploadOne-time larger import
Google Cloud Directory Sync (GCDS)Sync users/groups from on-prem LDAP / Active Directory on a schedule
SSO federation (SAML)Users authenticate against your existing IdP; Google trusts it
CompareSync identities, federate authentication

Two different jobs, two different tools.

GCDSCopies who exists (accounts, groups) from AD into Cloud Identity. "Keep AD as the source of truth for accounts" wants GCDS.
SAML SSODelegates how they log in to your IdP. "Let users sign in with their corporate password" wants SSO.

They're often used together.

Microsoft ActiveDirectory or LDAPUsers and groups in yourexisting directory serviceGoogle CloudDirectory SyncScheduledone-way syncUsers and groups in yourCloud Identity domain
Google Cloud Directory Sync: a scheduled, one-way push from your existing AD/LDAP into Cloud Identity - it never writes back to your directory.

Single sign-on (SSO)

With SSO you keep your own identity system for authentication. When a sign-in is needed, Google redirects the user to your IdP: if they're already authenticated there, Google grants access; otherwise they're prompted to log in. Because Google defers to your system, disabling a user there also revokes their Google Cloud access.

FactsSAML SSO setup
  • If your IdP supports SAML 2.0, setup is just three URLs (sign-in, sign-out, change-password) plus a verification certificate.
  • No SAML? Use a third-party IdP - ADFS, Ping, or Okta.
  • SSO handles login only - pair it with GCDS to also provision the accounts.

Recap

GotchaSuper Admin caution

The Cloud Identity super admin account is separate from GCP's Organization Admin and sits above the resource hierarchy. Protect it (MFA, break-glass, minimal use) - it can recover or take over the whole org.