Google Workspace & Access
Identity on the platform is anchored in Google Workspace groups. IAM roles are bound to groups (never to individuals), and almost nothing carries standing production access — elevated roles are granted just-in-time through Privileged Access Manager (PAM) with approval and a fixed time window.
Core groups
| Group | Purpose | Access |
|---|---|---|
| gcp-developers@u2i.com | Engineers building and shipping apps. | Standing roles/viewer on the org, plus Cloud Build editor on the bootstrap project. Eligible for the jit-deploy PAM entitlement. |
| gcp-prodsupport@u2i.com | Production support / on-call rotation (Lane 1). | No standing prod access. PAM-eligible for jit-deploy (30 min) and deployment-approver-access (2 h); approves Lane 1 elevations. |
| gcp-techlead@u2i.com | AppSec-trained tech leads; deployment reviewers. | Approves Lanes 1–4. PAM-eligible for jit-tf-admin (60 min) and deployment approvals. Acts as Security Reviewer. |
| gcp-techmgmt@u2i.com | Technical management; CEO/COO-level sign-off. | Final approver for all org-level changes. PAM-eligible for project bootstrap, billing, secret rotation, and break-glass. |
| gcp-billing@u2i.com | Finance / billing. | PAM-eligible for billing-access (4 h): billing.viewer + costsManager. |
| gcp-failsafe@u2i.com | Emergency break-glass identity (treated as an individual). | Standing right to act as the terraform-shared SA and OWNER on the org logging sink. Activation is separately alerted and audited. |
Per-application groups
Each app registered in the foundation gets its own groups, following a fixed naming pattern. The prodsupport group is what the Cloud Deploy prod approval gate checks against.
| Pattern | Example | Access |
|---|---|---|
| gcp-{app}-prodsupport@u2i.com | gcp-retrotool-prodsupport@u2i.com | Cloud Deploy approver + releaser on the tenant projects, and iam.serviceAccountUser to act as the app's deploy SA — this is the group that approves the prod promotion. |
| gcp-{app}-developers@u2i.com | gcp-retrotool-developers@u2i.com | A narrow custom role for app-specific needs (e.g. retrotool's role grants aiplatform.endpoints.predict for its Vertex AI summary feature). |
PAM entitlements (just-in-time elevation)
To touch production or org-level resources, an eligible group member requests an entitlement, an approver grants it, and the role is auto-revoked when the window expires. Every grant is logged to BigQuery and announced in Slack.
| Entitlement | Eligible | Approvers | TTL | Roles granted |
|---|---|---|---|---|
| jit-deploy (Lane 1) | developers, prodsupport, techlead | prodsupport, techlead, techmgmt | 30 min | clouddeploy.operator, container.developer, logging.viewer |
| jit-tf-admin (Lane 2) | techlead, techmgmt | techlead, techmgmt | 60 min | compute.admin, container.admin, iam.serviceAccountAdmin, storage.admin |
| jit-project-bootstrap (Lane 4) | techlead, techmgmt | techmgmt | 30 min | projectCreator, billing.projectManager, iam.organizationRoleAdmin, orgpolicy.policyAdmin |
| deployment-approver-access | prodsupport, techlead, techmgmt | prodsupport, techlead | 2 h | clouddeploy.approver + viewer, container.viewer, logging.viewer |
| billing-access | billing | techmgmt | 4 h | billing.viewer, billing.costsManager |
| compliance-secret-rotation | techmgmt | techmgmt | 1 h | secretmanager.secretVersionManager |
| break-glass-emergency (Lane 3) | failsafe | 2× techmgmt | 30 min | org-wide admin equivalent |
How approver groups gate a prod deploy
When an app declares an approver_group, the foundation (foundation/4-tenants/app-cicd.tf) creates three IAM bindings for that group so it — and only it — can advance a release to production:
roles/iam.serviceAccountUser # act as the app's Cloud Deploy SA
roles/clouddeploy.approver # approve the prod rollout
roles/clouddeploy.releaser # run: gcloud deploy releases promoteGroup management
The group-to-IAM bindings are defined in Terraform (foundation/1-organization and foundation/2-security), but group membership is managed in the Google Workspace Admin console — Terraform binds roles to a group email, it does not add or remove people. Adding someone to production support is therefore a Workspace membership change, not a code change.
Legacy groups
These predate the current tenure-based model and are being migrated out.
| Group | Purpose | Access |
|---|---|---|
| gcp-admins@u2i.com | Legacy admin group. | Migrating to gcp-techmgmt. |
| gcp-approvers@u2i.com | Legacy Cloud Deploy approver on the bootstrap project. | clouddeploy.releaser + approver; still used for Config Sync infra approvals. Being replaced by tenure-specific groups. |
| gcp-auditors@u2i.com | Legacy audit group. | billing.viewer (optional). Migrating to gcp-billing. |