SOP — Create and Manage a Google Cloud (GCP) Account

Key difference from AWS: you don't "sign up for a GCP account." The Organization resource is created automatically when you have Cloud Identity or Google Workspace for your domain. MPT Work already has Google Workspace for mptwork.com, so the GCP Organization exists and is governed by those super admins. Don't run workloads under the Organization without projects/folders, and don't use super admins for daily GCP work.

0. Plan the foundation

GCP resource hierarchy (top to bottom): Organization → Folders → Projects → Resources. IAM policies inherit downward. A recommended foundation layout:

Organization: mptwork.com
├── Folder: Bootstrap         (seed/Terraform, org-level automation)
├── Folder: Common            (logging, monitoring, org security, networking host)
├── Folder: Production        → prod projects
├── Folder: Non-Production    → staging/test projects
├── Folder: Development        → dev/sandbox projects
└── (optional) per-subsidiary folders: US / Japan / UK

For a governed baseline, use Google's Cloud setup guided onboarding and/or the Cloud Foundation Toolkit / Fabric FAST Terraform blueprints.

Part 1 — Establish the organization

1. The Organization node for mptwork.com is bound to your Cloud Identity / Workspace account. Confirm it exists in the Google Cloud console → IAM & Admin → Identity & Organization (you must be a Workspace super admin to claim/manage it).
2. If you did not want Workspace as the GCP identity source, you'd instead set up Cloud Identity Free on mptwork.com (verify the domain via TXT) — but since Workspace is in place, that's your identity foundation.
3. Confirm the domain is verified (already done for Workspace) so the Organization resource is active.

Part 2 — Secure the foundational identities

1. MFA/2-Step Verification is mandatory for Google Cloud. Ensure all admin and user accounts have 2SV; federated users satisfy it via their IdP (Entra). Prefer passkeys/security keys.
2. Protect super admins: Workspace super admins hold ultimate control. Keep them few, on @mptwork.com, with strong 2SV (security keys), and separate them from day-to-day GCP administration.
3. Create a break-glass super admin stored offline and excluded from any enforced SSO so it always works.
4. Don't use super admins for routine GCP tasks — they're for identity/org emergencies. Use dedicated admin accounts/groups with IAM roles (Part 5).

Part 3 — Set up the resource hierarchy

1. Grant the Organization Administrator IAM role to a small group (e.g., gcp-org-admins@mptwork.com) at the org level — distinct from Workspace super admin.
2. Create the Folders from section 0 (Bootstrap, Common, Production, Non-Production, Development).
3. Create a Bootstrap/seed project for org-level automation (Terraform state, CI identity).
4. Create projects under the appropriate folders; standardize naming (e.g., mptwork-prod-web, mptwork-dev-data).

Part 4 — Billing

1. Create a Cloud Billing account (IAM & Admin → Billing) with a billing-admin group gcp-billing-admins@mptwork.com.
2. Link projects to the billing account; consider one billing account for consolidated invoicing.
3. Set budgets and alerts, enable billing export to BigQuery, and review Cost reports regularly.

Part 5 — IAM and access

1. Grant access to Google Groups, not individuals (e.g., gcp-prod-admins@mptwork.com), at the folder/project level for inheritance.
2. Use predefined roles for least privilege; create custom roles where needed; avoid the broad primitive roles (Owner/Editor/Viewer) in production.
3. Service accounts: prefer Workload Identity Federation and attached service accounts; disable service-account key creation via org policy and avoid downloading keys.

Part 6 — Federate identity to Microsoft Entra (optional/recommended)

If Entra is your primary IdP (you maintain an Entra SOP):

1. SSO: federate Cloud Identity/Workspace to Entra via SAML so users authenticate through Entra (which enforces MFA/Conditional Access). Configure the Entra "Google Cloud / Workspace" gallery app.
2. Provisioning: sync users/groups from Entra using automatic provisioning (or Google Cloud Directory Sync from on-prem AD).
3. Alternative — Workforce Identity Federation: let Entra users access GCP without provisioning Cloud Identity accounts, using short-lived credentials.

This mirrors the federation pattern in the Entra and Workspace SOPs — pick Workspace-native identity or Entra-federated, and enforce MFA at the IdP.

Part 7 — Organization policies (guardrails)

Use the Organization Policy Service (parallel to AWS SCPs) to set constraints org-wide, for example:

• Domain-restricted sharing — allow IAM grants only to mptwork.com identities.
• Resource location restriction — limit to approved regions (e.g., US/Japan/UK regions).
• Disable service-account key creation and enforce OS Login.
• Restrict external IP on VM instances; require Shielded VMs.

Part 8 — Logging, monitoring, and security

1. Aggregated log sink: create an org-level Cloud Logging sink routing audit logs to a dedicated logging project (log bucket / BigQuery), in the Common folder.
2. Cloud Audit Logs: ensure Admin Activity and Data Access logs are captured.
3. Security Command Center (SCC): enable at the organization level for posture management and threat detection (Premium/Enterprise for advanced).
4. VPC Service Controls: define a service perimeter around sensitive data to prevent exfiltration.

Part 9 — Networking baseline (align to the IPAM plan)

1. Allocate VPC CIDRs from the enterprise IPAM plan — GCP blocks are US 10.4.0.0/14, Japan 10.20.0.0/14, UK 10.36.0.0/14 — and carve region/environment/VPC ranges per that scheme.
2. Use Shared VPC: a host project (in the Common/Network folder) owns the VPC and subnets; service projects attach to it. Recall GCP subnets are regional.
3. For GKE, use secondary ranges from the CGNAT space (pods 100.64.0.0/16, services 100.65.0.0/20) per the GCP VPC use-case design.
4. Connect to the global network (Cloud VPN/Interconnect to the Transit hub) per the network reference architecture; ensure no overlapping CIDRs.

Part 10 — Ongoing operations

Appendix — Notes, mapping, and caveats

AWS → GCP quick mapping

Caveats

• MFA/2SV is mandatory for Google Cloud; federated users meet it via the IdP — ensure Entra/Workspace enforce it. Protect and minimize super admins; keep a break-glass.
• The Organization is inseparable from Cloud Identity/Workspace on mptwork.com — losing control of those super admins means losing org control.
• No primitive Owner/Editor in prod; grant to groups with least-privilege predefined/custom roles; disable SA key downloads.
• GCP subnets are regional (not zonal) — size ranges accordingly from the IPAM plan.
• Verify current steps in Google Cloud documentation — console layout, SCC tiers, and federation options change frequently.