Anatomia di una VPC: subnet e firewall

Una VPC in Google Cloud è una risorsa globale: attraversa tutte le region senza VPN o gateway intermedi. Le subnet, invece, sono regionali e definiscono un primary IP range; puoi aggiungere secondary ranges, usati tipicamente dagli alias IP e dai pod/service di GKE. In produzione scegli la modalità custom (non auto), per controllare esplicitamente CIDR e region.

Le firewall rule si definiscono a livello di VPC ma vengono valutate sulla singola VNIC dell’istanza. Sono stateful e ordinate per priority (valore più basso = precedenza più alta). Esistono due regole implicite: deny su tutto l’ingress e allow su tutto l’egress. I target si selezionano per network tag o service account: preferisci il service account, non falsificabile come un tag. Per policy trasversali su più progetti usa le hierarchical firewall policy a livello di org o folder; per ispezione L7/IDS valuta Cloud NGFW nel tier Enterprise.

Puoi espandere il primary range di una subnet dopo la creazione (solo allargarlo, mai restringerlo) purché il nuovo CIDR non si sovrapponga ad altre subnet o a range di reti peered.

VPC Network Peering vs Shared VPC

Sono due modi diversi di collegare ambienti, spesso confusi all’esame.

VPC Network Peering collega due VPC (anche di org/progetti diversi) con connettività privata RFC1918; nessuna subnet può sovrapporsi e ogni lato deve configurare il proprio versante. Il punto critico: il peering non è transitivo. Se A è in peering con B e B con C, A non raggiunge C. Per una topologia hub-and-spoke con transitività serve Network Connectivity Center.

Shared VPC centralizza la rete in un host project che condivide le subnet con i service project. Le VM vivono nei service project ma usano subnet, route e firewall governate centralmente. I ruoli IAM chiave:

  • Shared VPC Admin (compute.xpnAdmin), assegnato a livello di org/folder, abilita l’host e collega i service project;
  • Network User (compute.networkUser), assegnato al team del service project sull’intero host o sulla singola subnet, permette di creare risorse in quella subnet.

Usa Shared VPC quando vuoi amministrazione di rete centralizzata con autonomia dei team; usa il peering per collegare VPC che restano amministrativamente indipendenti.

Accesso privato alle API Google

Private Google Access si abilita per subnet e consente alle VM prive di IP esterno di raggiungere le API e i servizi Google restando sulla rete Google. Non confonderlo con concetti vicini:

  • private services access: peering verso la rete del producer per servizi gestiti come Cloud SQL o Memorystore (richiede un range IP allocato);
  • Private Service Connect: espone un endpoint privato con IP interno nella tua VPC verso le API Google o servizi pubblicati.

Per le VM senza IP pubblico che devono uscire verso Internet (e non verso le API Google) serve invece Cloud NAT, che fa solo egress e non è né ingress né un firewall.

VPC Service Controls

VPC Service Controls crea un perimetro attorno ai servizi gestiti (BigQuery, Cloud Storage, ecc.) per prevenire l’esfiltrazione dei dati: una chiamata API che attraversa il confine del perimetro viene bloccata salvo ingress/egress rule o access level espliciti. È un controllo anti-esfiltrazione, non un firewall: non filtra pacchetti IP verso le VM, ma limita l’accesso ai servizi a livello di API. Usa la modalità dry-run per osservare le violazioni prima di applicare il perimetro.

Trappole tipiche d’esame

  • A deve parlare con C attraverso un hub B → soluzione: il VPC Peering non è transitivo; serve Network Connectivity Center, non un terzo peering.
  • Impedire l’esfiltrazione di dati da un bucket Cloud Storage → soluzione: VPC Service Controls, non una firewall rule (che opera a livello IP sulle VM).
  • VM senza IP esterno deve leggere da BigQuery/Cloud Storage → soluzione: Private Google Access sulla subnet, non Cloud NAT (che serve per l’egress Internet generico).
  • Un team nel service project non riesce a creare VM nella subnet condivisa → soluzione: manca il ruolo Network User sulla subnet (o sull’host), distinto dallo Shared VPC Admin che collega i progetti.
  • Serve più spazio IP in una subnet già in uso → soluzione: espandi il primary range (solo allargamento, nessuna sovrapposizione), senza ricrearla.
  • Bloccare traffico solo da alcune istanze → soluzione: target firewall per service account anziché network tag, modificabile da chi controlla la VM.