Cloud Identity
Cloud Identity is the directory behind a Google Cloud organization: its users, groups and sign-in settings, shared with Google Workspace when the organization has it. The GCP Enterprise Baseline grants access to people only through 14 Google groups, so membership is the one place access changes.
What it does
Every Google Cloud organization belongs to one Cloud Identity or Google Workspace customer, which owns the organization's domain, its users and its groups. IAM can bind a role to a group by its email address, and every member of the group receives it. Sign-in policies, such as 2-Step Verification and the Google Cloud session length, are customer settings in the Admin console. The organization policy iam.allowedPolicyMemberDomains keeps IAM bindings to members of the organization's own customer.
How BuiltForProd uses it
The groups-iam unit (environments/core/identity/global) names 14 groups, acme-<role>@company.com:
| Group | Purpose |
|---|---|
acme-platform-leads, acme-platform-engineers | Own the landing zone |
acme-devops-leads, acme-devops-engineers | Own the stage projects and their delivery |
acme-lead-app-developers, acme-app-developers | Web application teams |
acme-lead-etl-engineers, acme-etl-engineers | Data and ETL teams |
acme-lead-ai-engineers, acme-ai-engineers | AI teams |
acme-all-engineers | Read-only view of prod for every engineer |
acme-lead-security-auditors, acme-security-auditors | Configuration and audit-log review, never data |
acme-break-glass | Emergency access |
The switches live in environments/core/identity/identity.hcl. With create_groups = false, the default, IT creates the groups in Cloud Identity or Google Workspace and the unit looks each one up by email; a missing group fails the plan loudly. With create_groups = true the unit creates them under the organization's customer ID instead. Either way, Identity and Access Management binds roles to the groups, never to individual users.
Sign-in settings. 2-Step Verification enforcement and a 12-hour Google Cloud session length are Admin console settings that the Baseline expects to be in place; the code does not set them.
Break-glass accounts. Break-glass accounts are individual Cloud Identity super administrators. The organization sink routes the Cloud Identity sign-in audit logs (login.googleapis.com) into the central log bucket once the Admin console shares them with Google Cloud, and the log-based detection super-admin-signin raises an alert on every successful sign-in of an account listed in break_glass_emails of the cis-alerts unit. The detection exists as soon as one account is listed. Cloud Monitoring delivers the alert to the security mailbox.
Terms you will see
| Term | Meaning |
|---|---|
| Customer | The Cloud Identity or Google Workspace account that owns the organization. |
| Group key | The group's email address, the ID IAM binds to. |
create_groups | The switch that makes the Baseline create the groups instead of looking them up. |
| Break-glass account | A super administrator kept for emergencies, whose sign-ins raise an alert. |
| 2-Step Verification | The Cloud Identity second factor, enforced for the organization. |
Where to read more
- GCP Enterprise Baseline overview for how people reach the platform.
- Privileged Access Manager for time-bound Owner access of the lead groups.
- Least privilege for granting through groups only.