Organisation, projects & Shared VPC

Start with the hierarchy

Organization (example.com)
├── Folder: platform
│   ├── net-host-prod        Shared VPC host (prod)
│   ├── net-host-nonprod     Shared VPC host (dev, staging)
│   └── platform-shared      Artifact Registry, CI identities, DNS
├── Folder: prod
│   ├── gke-prod             clusters (service project of net-host-prod)
│   └── data-prod            databases, buckets
└── Folder: nonprod
    ├── gke-dev, gke-staging
    └── data-nonprod

Projects are the blast-radius, IAM, quota and billing boundary. Separate prod from non-prod by project (and usually by folder), so a mistake or a compromised credential in dev can't touch production. Organization policies set at the folder level apply to every project below.

Shared VPC

What GKE in a service project needs, in the host project:

• The service project's GKE service agent (service-<PROJECT_NUMBER>@container-engine-robot.iam.gserviceaccount.com) gets the Host Service Agent User role on the host project.
• The GKE service agent and the Google APIs service agent of the service project get Compute Network User on the subnets the cluster uses (subnet-level grants keep teams in their own subnets).
• Firewall rules: GKE wants to create rules for its control plane, health checks and load balancers. Either give it the Security Admin role in the host (simplest), or let the network team create those rules and accept that GKE reports what it couldn't create.

Subnets for GKE

A GKE subnet has three ranges (sizes in lesson 04):

gcloud compute networks subnets create gke-prod-ew1 \
  --project net-host-prod --network prod-vpc --region europe-west1 \
  --range 10.10.0.0/22 \
  --secondary-range pods=10.20.0.0/16,services=10.30.0.0/20 \
  --enable-private-ip-google-access

• Primary range: node IPs (and internal load balancers).
• Secondary range for Pods, secondary range for Services: used by the VPC-native cluster.
• One subnet per region per environment is a common start; a separate subnet per cluster keeps IP plans and firewall rules cleaner when you run several clusters.

Egress: Cloud NAT and Private Google Access

Production nodes are private (no external IPs). They still need:

Size Cloud NAT for busy clusters: each NAT IP has a fixed number of source ports, and many connections to the same destination can exhaust them. Watch the NAT dropped-packets metrics, and use dynamic port allocation or more NAT IPs if needed.

Firewall rules

• GKE creates the rules it needs (control plane to nodes, node-to-node, health checks for load balancers).
• Add your own as hierarchical firewall policies (org or folder) and network firewall policies for broad rules (deny everything from the internet except the load balancers' ranges), and target node rules by service account rather than network tags where you can.
• Inside the cluster, network policy controls Pod-to-Pod traffic (lesson 04); VPC firewall rules don't see individual Pods unless you design for it.

Organization policies worth setting early

• Allowed regions for resources.
• No external IPs on VMs (private nodes everywhere).
• Restrict which projects may use Shared VPC subnets.
• Require OS Login, disable default service-account grants, require CMEK where compliance needs it.

Test policies on a non-prod folder first: some block GKE operations in non-obvious ways (for example a policy forbidding external IPs also blocks public node pools).

Recap

• Organization → folders → projects; projects separate prod from non-prod.
• Shared VPC: the network team owns the host project; clusters live in service projects with subnet-level access.
• GKE subnets have a primary range for nodes and secondary ranges for Pods and Services.
• Private nodes need Private Google Access for Google APIs and Cloud NAT for the internet.
• Set organization policies and firewall policies early, and test them in non-prod.