Q: How do you design a multi-tier Shared VPC architecture in GCP for an enterprise with 20 product squads? How do you grant squads network access without letting them alter firewall rules or routing tables?
Architectural playbook for deploying a centralized Google Cloud Shared VPC across Host and Service Projects, ensuring security isolation, subnetwork IAM delegation, and centralized egress filtering.
#GCP #Shared VPC #Networking #IAM #VPC #Security
🎙️ Candidate Opening & Architectural Context
"In a large enterprise migration to GCP, product teams needed autonomous control over their Compute Engine and GKE clusters while network engineers required strict central governance over IP ranges, firewalls, and Cloud NAT."
Advertisement
⚡ Recommended Practice Lab
Want to master this scenario in a live sandbox? Stephane Maarek's AWS Certified DevOps Engineer Professional Masterclass on Udemy covers this exact problem with hands-on terminal drills.
🛠️ Production Runbook & Step-by-Step Resolution
1️⃣
Designate Host Project & Subnet IP Carving
Establish a dedicated Network Host Project with non-overlapping RFC 1918 CIDR allocations:
- Host Project: Designated
network-core-prodas the Shared VPC Host Project. - Subnet Segregation: Created private subnets across regions:
subnet-prod-us-central1 (10.100.0.0/20)with secondary alias ranges for GKE Pods and Services. - Cloud Router & NAT: Deployed regional Cloud Routers with Cloud NAT for private internet egress.
Pro Tip: Shared VPC requires that the host project and service projects belong to the same Google Cloud Organization.
2️⃣
Attach Service Projects & Delegate Subnet Permissions
Attach application projects to the host project and grant granular IAM roles:
- Attach Projects: Attached
billing-app-prodandauth-app-prodas Service Projects. - Subnet User Role: Granted
roles/compute.networkUserstrictly at the individual subnetwork level, not project level. - Targeted Access: Service projects can deploy VMs/GKE onto their designated subnet, but cannot view or attach to other squads' subnets.
Pro Tip: Never grant compute.networkUser at the host project level; always scope it to specific subnets to enforce least privilege.
3️⃣
Grant Permissions for GKE Service Agents
Allow GKE in service projects to manage firewall rules and load balancers:
- GKE Service Agent: Granted
roles/container.hostServiceAgentUserto the Service Project GKE Service Agent on the Host Project. - Google APIs Service Agent: Granted
roles/compute.networkUserto the Google APIs service agent in the host project.
Pro Tip: Without hostServiceAgentUser, GKE in service projects cannot provision Cloud Load Balancers or manage firewall rules for Ingress.
4️⃣
Enforce Hierarchical Firewall Policies & Cloud DNS Peering
Centralize security governance and private service resolution:
- Hierarchical Firewall Policies: Enforced mandatory organization-level rules (e.g. block SSH 0.0.0.0/0, mandate IAP bastion).
- Cloud DNS Private Zones: Hosted all private domains in the Host Project and established DNS Peering with on-premises datacenters.
Pro Tip: Hierarchical firewall policies take evaluation precedence before any individual VPC firewall rules can be processed.
💡 The Senior SRE Gold Nugget (Key Architectural Takeaway)
"Shared VPC allows network engineers to retain centralized control over routing, peering, and firewalling while giving product development squads complete autonomy to manage compute workloads in their own GCP projects."
⚡ 60-Second Elevator Pitch Talking Points
- Created a centralized Host Project managing shared regional subnets with secondary GKE IP ranges.
- Attached product service projects and granted compute.networkUser strictly at the individual subnetwork level.
- Provisioned GKE hostServiceAgentUser permissions so container clusters could deploy Cloud Load Balancers.
- Enforced organizational hierarchical firewall policies to guarantee zero public ingress without IAP.
Advertisement