Tanquem el mòdul 2 amb un diagnòstic incòmode: tot el que AlpinaShop ha construït està exposat. La VM alpinashop-web-1 té el port 80 obert a internet i el 22 accessible des de qualsevol adreça, la instància alpinashop-pedidos és abastable per IP pública, el Service de GKE va publicar una IP sense HTTPS i no existeix cap frontera entre el que ha de ser públic i el que no ho hauria de ser mai. Aquesta lliçó construeix aquesta frontera.

La xarxa és la capa sobre la qual s'apuntala tot la resta. Abans de posar un balancejador, un CDN o un WAF cal decidir on viu cada màquina, quins rangs d'adreces fa servir, qui pot parlar amb qui i per on surt el trànsit cap a internet. A Google Cloud aquesta decisió es materialitza en una VPC (Virtual Private Cloud): una xarxa privada definida per programari, aïllada de la resta de clients, dins de la qual conviuen les teves instàncies, els teus clústers, les teves bases de dades i els teus balancejadors.

La xarxa VPC de Google Cloud té una propietat que sorprèn qui ve d'AWS o d'un centre de dades tradicional: és global. Una única xarxa pot abastar totes les regions del planeta, i dues màquines a Bèlgica i a Tòquio dins de la mateixa VPC es parlen per IP privada sense túnels ni passarel·les. Les subxarxes, en canvi, són regionals. Entendre aquesta asimetria és el 80 % d'entendre la xarxa de Google.

En aquesta lliçó dissenyaràs i implementaràs la xarxa alpinashop-vpc amb les seves subxarxes, planificaràs l'adreçament sense encavalcaments, escriuràs el conjunt real de regles de tallafoc d'AlpinaShop, donaràs sortida a internet a màquines sense IP pública amb Cloud NAT, arribaràs a les APIs de Google sense passar per internet amb Private Google Access i connectaràs per fi alpinashop-pedidos per IP privada.

Avís. Aquesta lliçó té implicacions de seguretat directes. El disseny que es proposa és raonable per a una pime com AlpinaShop, però qualsevol arquitectura de xarxa que hagi d'anar a producció l'ha de revisar un professional de seguretat, i si tractes dades personals o mitjans de pagament, també un responsable de compliment normatiu.

1. Què és una VPC i en què es diferencia d'una xarxa tradicional
2. Xarxa per defecte, mode automàtic i mode personalitzat
3. Planificació de l'adreçament: CIDR sense encavalcaments
4. Creació d'alpinashop-vpc i les seves subxarxes
5. Rangs secundaris per a GKE
6. Adreces IP internes i externes, efímeres i estàtiques
7. Regles de tallafoc VPC: el model complet
8. El conjunt real de regles d'AlpinaShop
9. Rutes i la passarel·la per defecte
10. Cloud NAT: sortida a internet sense IP pública
11. Private Google Access: arribar a les APIs sense sortir a internet
12. Accés privat a serveis: Cloud SQL per IP privada
13. VPC Flow Logs: diagnòstic i auditoria
14. Què queda fora d'aquesta lliçó

En un centre de dades clàssic, la xarxa és física: switches, VLAN, cablejat, rangs que algú va apuntar en un full de càlcul fa vuit anys. A Google Cloud, la xarxa és una abstracció de programari muntada sobre la xarxa global de Google. Les diferències pràctiques són aquestes:

Tres conseqüències que convé gravar des del principi:

• La xarxa és un recurs global del projecte. No pertany a una regió. Quan crees alpinashop-vpc a alpinashop-prod, existeix a tot arreu.
• Les subxarxes són regionals, no zonals. Una subxarxa a europe-west1 cobreix europe-west1-b, -c i -d. Una VM a qualsevol d'aquestes zones pot prendre una IP d'aquesta subxarxa. Això és el que permet que el MIG regional alpinashop-web-mig reparteixi instàncies entre tres zones fent servir una sola subxarxa.
• El tallafoc no és "en un lloc". No hi ha un tallafoc perimetral pel qual passi el trànsit: cada regla s'aplica a l'hipervisor, a la mateixa interfície de xarxa de cada VM. Per això el trànsit entre dues VM de la mateixa subxarxa també està subjecte a regles, i per això no pots "saltar-te" el tallafoc posant les màquines juntes.

Quan vas crear el projecte alpinashop-prod, Google va crear automàticament una xarxa anomenada default. És còmoda per provar i mala idea per a producció. Vegem per què.

Existeixen dos modes de xarxa:

La xarxa default és de mode automàtic i a més porta regles de tallafoc preconfigurades que obren el port 22 (SSH) i el 3389 (RDP) a tot internet. Això és exactament el problema que AlpinaShop arrossega des del mòdul 2.

Tota organització seriosa fa servir mode personalitzat per tres motius:

1. Control de l'adreçament. Si demà AlpinaShop connecta la seva oficina per VPN (tema de 07-03), els rangs no poden xocar. Amb mode automàtic, Google decideix per tu a totes les regions presents i futures.
2. Superfície d'atac mínima. No hi ha subxarxes a regions que no fas servir ni regles permissives que algú es va oblidar de revisar.
3. Reproductibilitat. La xarxa es descriu en codi (Terraform, a 06-07) i es recrea idèntica a alpinashop-dev.

La primera tasca real, doncs, és crear una xarxa personalitzada i deixar de fer servir default:

Més endavant, quan tot estigui migrat, la xarxa default s'elimina. No s'elimina el primer dia: hi ha recursos vius a dins. L'ordre correcte és crear la xarxa nova → moure càrregues → esborrar la vella.

Abans d'escriure una sola comanda, es planifica sobre paper. Un pla d'adreçament dolent es paga durant anys, perquè el rang primari d'una subxarxa es pot ampliar, però no reduir ni moure, i perquè dues xarxes amb rangs encavalcats no es poden connectar mai.

Recordatori mínim de CIDR:

Google reserva quatre adreces a cada subxarxa: la de xarxa, la passarel·la (sempre la segona, x.x.x.1), i dues reservades per a ús futur (les dues últimes). Per això un /24 dona 252 IP utilitzables, no 254.

El pla d'AlpinaShop reserva el bloc privat 10.10.0.0/16 per a producció i deixa espai deliberat entre subxarxes:

Regles d'or en planificar:

• No facis servir mai 10.0.0.0/24 ni 192.168.1.0/24. Són els rangs que fa servir mig món, inclosa la xarxa domèstica dels teus companys; el dia que hi hagi VPN, xocaran.
• Deixa forats. És més fàcil demanar perdó que reorganitzar adreces.
• Documenta el pla i versiona'l. El document d'adreçament viu al repositori, no a la memòria de la Marta.
• Els rangs de pods de Kubernetes són grans. Un /16 per a pods no és exagerat: GKE reserva un bloc per node.

Amb el pla tancat, la implementació són tres comandes:

Dos paràmetres mereixen explicació:

• --subnet-mode=custom: no crea cap subxarxa automàticament. És el que volem.
• --bgp-routing-mode=global: quan en el futur hi hagi un Cloud Router (VPN o Interconnect, tema de 07-03), les rutes apreses es propagaran a totes les regions, no només a la de l'encaminador. És el valor correcte per a una xarxa que pot créixer; canviar-lo després obliga a reconfigurar l'encaminador.

Què fa cada opció, en detall:

• --range: el rang primari. És el que es reparteix entre les interfícies de les VM.
• --enable-private-ip-google-access: permet que una VM sense IP pública arribi a les APIs de Google (Cloud Storage, BigQuery, Secret Manager…). Ho desenvolupem a l'apartat 11. Activa'l sempre; no té cost ni contraindicació.
• --enable-flow-logs i els seus paràmetres: activa el registre de fluxos. --logging-flow-sampling=0.5 mostreja la meitat dels fluxos, cosa que redueix el cost de registres a la meitat mantenint utilitat de diagnòstic. Ho veiem a l'apartat 13.

Comprovació:

Veuràs que gatewayAddress és 10.10.0.1: la passarel·la sempre és la segona adreça del rang, i no és una màquina que puguis tocar, sinó una funció distribuïda de la xarxa.

El clúster alpinashop-cluster que vam crear a 02-05 necessita adreces per a pods i per a services, i aquestes adreces no surten del rang primari de la subxarxa, sinó de rangs secundaris (el que Google anomena alias IP ranges). Aquest és el model de xarxa nativa de VPC de GKE, i és el que es fa servir sempre a Autopilot.

Per què rangs tan grans:

La conseqüència de més abast: amb xarxa nativa de VPC, un pod té una IP real de la VPC. No hi ha NAT intern entre pods i VM. Això significa que una regla de tallafoc pot referir-se directament al rang de pods, i que una VM de sn-datos-euw1 pot rebre trànsit d'un pod i veure'n la IP d'origen autèntica. És més simple de raonar i més fàcil d'auditar.

En crear un clúster nou s'indiquen els rangs així (referència per a quan recreïs el clúster a la xarxa nova):

Cada VM té sempre una IP interna (de la subxarxa) i, opcionalment, una IP externa. I cadascuna pot ser efímera (s'assigna en arrencar i es perd en aturar la màquina) o estàtica (reservada, sobreviu a la instància).

Reservem ja la IP global que farà servir el balancejador de la lliçó següent i les IP que necessitarà Cloud NAT:

Reservar la IP de sortida de NAT té un avantatge concret: la passarel·la de pagament d'AlpinaShop exigeix una llista d'IP autoritzades. Si la IP de sortida fos efímera, canviaria en recrear el NAT i el cobrament deixaria de funcionar un dimarts a la tarda sense motiu aparent.

Un advertiment de facturació: una IP externa estàtica reservada i no associada a res es factura igualment, i a una tarifa més alta que si estigués en ús. És una de les fuites de cost més habituals. Revisa-les periòdicament:

El tallafoc de VPC és stateful (si permets la connexió d'entrada, la resposta surt sense necessitat de regla) i distribuït (s'aplica a cada interfície). Una regla té aquests elements:

A més existeixen quatre regles implícites que no veus a la llista i no pots esborrar:

La conseqüència pràctica és la que defineix la disciplina de treball: per defecte no entra res i surt tot. Tot el que vulguis permetre d'entrada s'ha d'escriure; tot el que vulguis impedir de sortida, també.

És la decisió de disseny més important del tallafoc. Es pot seleccionar a quines màquines s'aplica una regla de dues maneres:

AlpinaShop fa servir un model mixt i explícit: etiquetes per a les regles d'entrada des d'internet (on la llegibilitat importa i les màquines són del MIG) i comptes de servei per a l'accés a dades. I documenta aquesta decisió, perquè barrejar els dos criteris sense criteri és una font clàssica de forats.

Aquest és el conjunt complet. Llegeix-lo sencer abans d'executar-lo: cada regla respon a una necessitat concreta.

Diagrama del resultat:

És el patró més estès i el més perillós. Obrir tcp:22 a 0.0.0.0/0 significa literalment que qualsevol màquina del planeta pot intentar autenticar-se al teu servidor. Les conseqüències no són teòriques:

• Un servidor amb el 22 obert rep milers d'intents d'autenticació al dia des del primer minut. Els escàners automàtics escombren els rangs de tots els proveïdors de núvol contínuament.
• N'hi ha prou amb una credencial feble, una clau reutilitzada o una fallada a sshd perquè es converteixi en una intrusió.
• El soroll als registres amaga els atacs reals.
• Tanca la porta a la traçabilitat: no saps qui va entrar, només quina clau es va fer servir.

L'alternativa correcta és IAP TCP forwarding, la regla número 2 del bloc anterior. Amb ella:

• Les VM no necessiten IP pública.
• L'accés passa per Google, que exigeix autenticació amb la identitat corporativa (Marta, Dani) i aplica IAM: qui no tingui el rol roles/iap.tunnelResourceAccessor no arriba ni a la salutació d'SSH.
• Cada sessió queda registrada amb la identitat real de la persona.

Els detalls d'IAP i els seus permisos els desenvolupem a 03-04 (IAM); aquí n'hi ha prou de saber que la regla de tallafoc del 22 apunta a 35.235.240.0/20 i mai a internet.

Les rutes decideixen per on surt un paquet. Cada VPC neix amb dos tipus de ruta automàtiques:

Que la ruta per defecte es pugui esborrar és una eina de seguretat molt potent: si elimines la ruta 0.0.0.0/0 d'una VPC, cap màquina d'aquesta xarxa pot sortir a internet, ni tan sols amb IP pública. És el patró de les xarxes aïllades per al tractament de dades sensibles. AlpinaShop no hi arriba en producció, però és útil per al projecte d'anàlisi de la Lucía si algun dia tracta dades personals.

Les rutes personalitzades (per exemple, enviar cert trànsit a un appliance de xarxa) i les rutes apreses per BGP des d'una VPN pertanyen a 07-03.

Ja hem dit que les VM no han de tenir IP pública. Però necessiten sortir a internet per actualitzar paquets del sistema, instal·lar dependències de Python o cridar l'API de la passarel·la de pagament. La solució és Cloud NAT: un servei gestionat, sense instàncies que mantenir, que tradueix les adreces privades a una o diverses IP públiques de sortida.

Punts clau:

• Cloud NAT és només de sortida. Ningú no pot iniciar una connexió des d'internet cap a una VM a través d'ell. És exactament el que volem.
• No és una màquina: no hi ha coll d'ampolla que dimensionar ni pedaços que aplicar.
• Es configura per regió i s'associa a un Cloud Router, que en aquest cas no fa BGP: és només el punt d'ancoratge del servei.

Detall de les opcions:

• --nat-custom-subnet-ip-ranges: només aquestes dues subxarxes surten per NAT. L'alternativa (--nat-all-subnet-ip-ranges) és còmoda però menys explícita.
• --nat-external-ip-pool=alpinashop-nat-ip: fa servir la nostra IP estàtica. Aquesta és l'adreça que AlpinaShop comunica a la passarel·la de pagament per a la seva llista d'autoritzats. L'alternativa --auto-allocate-nat-external-ips deixa que Google triï, i les IP poden canviar.
• --min-ports-per-vm=128: cada VM reserva 128 ports d'origen. És el paràmetre que causa la fallada més típica de Cloud NAT: si una màquina obre moltes connexions sortints simultànies (per exemple, un treball que descarrega milers de fitxers) i es queda sense ports, les connexions noves fallen amb un error confús. El símptoma es veu a les mètriques com a nat_allocation_failed.
• --log-filter=ERRORS_ONLY: registra només les fallades. ALL genera un volum de registres considerable i cost associat.

Verificació des d'una VM sense IP pública:

Quan una VM sense IP pública crida storage.googleapis.com per llegir del bucket alpinashop-catalogo, per on va aquest trànsit? Hi ha dues respostes possibles, i la bona no és l'evident.

• Sense Private Google Access: la petició surt per Cloud NAT, va a internet, resol una IP pública de Google i torna. Funciona, però surt de la xarxa de Google, consumeix capacitat de NAT i es factura com a trànsit de sortida.
• Amb Private Google Access activat a la subxarxa: la petició s'encamina internament cap als frontals de les APIs de Google. No passa per internet, no consumeix ports de NAT i no es factura com a egress a internet.

Ja el vam activar en crear les subxarxes amb --enable-private-ip-google-access. Si necessites activar-lo després:

És una opció que ha d'estar activada sempre, a totes les subxarxes, a tots els entorns. No té cost, no té contraindicació i afecta gairebé tot el que farà AlpinaShop: llegir el bucket, escriure a BigQuery (mòdul 4), llegir un secret de Secret Manager (03-06) o descarregar una imatge d'Artifact Registry.

Existeix una variant, Private Service Connect, que permet arribar a APIs de Google o serveis de tercers per una IP privada teva, amb control de DNS. És una peça d'arquitectures més grans i s'estudia a 07-03.

A 02-03 vam crear alpinashop-pedidos amb IP pública i ens hi vam connectar amb l'Auth Proxy. Funcionava, però la instància era abastable des d'internet (encara que protegida per xarxes autoritzades i credencials). Ara la movem a IP privada, que és la configuració correcta.

El mecanisme s'anomena accés privat a serveis i consisteix en això: cedeixes un rang de la teva VPC a Google, Google hi crea els recursos gestionats (la instància de Cloud SQL) i estableix un emparellament entre la teva xarxa i la seva. Des de la teva VPC, la base de dades apareix amb una IP normal d'aquest rang.

Implementació, pas a pas:

Amb la connexió establerta, s'assigna la IP privada a la instància i es retira la pública:

Detalls que eviten ensurts:

• --no-assign-ip retira la IP pública. Fes-ho només quan hagis verificat que la connexió privada funciona des d'una VM; si no, et quedes sense accés fins a revertir-ho.
• El rang cedit no es pot reduir després sense recrear la connexió. Un /20 dona marge per a instàncies futures (la rèplica alpinashop-pedidos-replica-informes també consumeix adreces d'aquí).
• La cadena de connexió de l'aplicació Flask canvia de la IP pública a la privada; l'Auth Proxy continua sent vàlid i continua sent l'opció recomanada perquè afegeix xifratge i autenticació IAM, però ja no és l'única manera d'arribar-hi.
• El canvi de xarxa d'una instància de Cloud SQL implica reinici. Planifica-ho fora d'horari comercial.

Els registres de flux graven una mostra de les connexions que travessen les interfícies de les VM: origen, destí, ports, bytes, paquets, i si van ser permeses o denegades. Serveixen per a tres coses:

1. Diagnosticar per què alguna cosa no connecta (va arribar el paquet? el va denegar una regla?).
2. Auditar: veure a quins destins externs parla realment la teva infraestructura.
3. Analitzar el cost de trànsit entre zones i regions.

Ja els vam activar en crear les subxarxes. Una consulta típica a Cloud Logging (el servei s'estudia a fons a 06-06; aquí el fem servir com a eina):

Consideracions de cost i privadesa:

• Els flow logs es facturen per volum de registres ingerits. En una xarxa amb trànsit intens, el mostreig al 100 % pot ser car. 0.5 és un punt de partida raonable; 0.1 per a trànsit molt alt.
• Contenen adreces IP de clients, que a la Unió Europea són dada personal. Fixa una política de retenció d'acord amb l'RGPD i documenta el tractament. Aquesta és una d'aquelles decisions que ha de validar el responsable de compliment abans de producció.

A més dels flow logs, per a diagnòstic puntual hi ha el Network Intelligence Center i la seva eina de proves de connectivitat, que simula un paquet i et diu exactament quina regla el va permetre o denegar, sense generar trànsit real:

Perquè no et quedi la sensació de buit, això és el que existeix i no hem tractat aquí:

• Fer servir la xarxa default en producció. Porta subxarxes a totes les regions i regles que obren SSH i RDP a internet. Crea una xarxa personalitzada des del principi i esborra la default quan ja no quedin recursos a dins.
• Obrir tcp:22 a 0.0.0.0/0. L'error clàssic. Fes servir IAP amb la regla des de 35.235.240.0/20 i treu les IP públiques de les VM.
• Oblidar els rangs del balancejador. Si no permets 130.211.0.0/22 i 35.191.0.0/16, les comprovacions d'estat fallen, el backend es marca com a no saludable i el balancejador retorna 502 sense explicació clara. És, amb diferència, la fallada número u de la lliçó següent.
• Triar rangs "còmodes" com 10.0.0.0/16 o 192.168.1.0/24. Xocaran el dia de la VPN. Planifica i documenta l'adreçament abans de crear res.
• Creure que les subxarxes són zonals. Són regionals. No necessites una subxarxa per zona; una subxarxa regional serveix un MIG regional en tres zones.
• Confondre prioritat alta amb número alt. Al tallafoc de VPC guanya el número menor. Una regla allow amb prioritat 100 venç una deny amb prioritat 1000.
• Deixar IP externes estàtiques reservades sense fer servir. Es facturen, i a tarifa superior. Audita gcloud compute addresses list --filter="status=RESERVED" cada mes.
• No activar Private Google Access. Sense ell, tot el trànsit a les APIs de Google surt per NAT a internet: més cost, més latència i esgotament de ports de NAT.
• Retirar la IP pública de Cloud SQL abans de comprovar la privada. Verifica primer la connectivitat privada des d'una VM i després aplica --no-assign-ip.
• Dimensionar malament min-ports-per-vm a Cloud NAT. Un treball per lots amb moltes connexions sortints esgota els ports i provoca fallades intermitents difícils d'atribuir. Vigila la mètrica de fallades d'assignació.
• Confiar només en el tallafoc. El tallafoc de VPC controla el nivell de xarxa. L'autenticació, l'autorització i la validació d'entrada continuen sent responsabilitat de l'aplicació.

La Marta necessita replicar la xarxa al projecte alpinashop-dev. El requisit és que els rangs no encavalquin amb producció (10.10.0.0/16, secundaris 10.20.0.0/16 i 10.21.0.0/20, accés privat a serveis 10.30.0.0/20) ni amb l'oficina (192.168.10.0/24), perquè en el futur es connectaran tots dos entorns.

Dissenya el pla (xarxa, dues subxarxes a europe-west1, rangs secundaris de GKE i rang per a serveis gestionats) i escriu les comandes gcloud que el creen, amb Private Google Access activat.

La Lucía necessita una VM d'informes anomenada alpinashop-informes-1 a sn-datos-euw1, amb l'etiqueta informes, que compleixi:

1. Només la Lucía i la Marta poden entrar per SSH, i únicament a través d'IAP.
2. La VM ha de poder consultar la rèplica alpinashop-pedidos-replica-informes pel port 5432.
3. La VM no ha de rebre trànsit des d'internet ni des de la capa web.
4. La VM ha de poder descarregar paquets de PyPI (sortida a internet) sense tenir IP pública.

Escriu les regles de tallafoc necessàries i explica quin component resol el punt 4.

Després de crear el balancejador (avançament de la lliçó següent), el catàleg retorna 502 i a la consola els backends del MIG apareixen com a UNHEALTHY. L'aplicació respon correctament si fas curl http://10.10.0.5:8080/salud des d'una altra VM de la mateixa subxarxa.

Enumera les tres causes més probables per ordre de probabilitat i la comanda que faries servir per confirmar o descartar cadascuna.

Solució 1

Pla proposat (bloc 10.60.0.0/16 reservat al document d'adreçament per a desenvolupament):

Cap no encavalca amb 10.10/16, 10.20/16, 10.21/20, 10.30/20 ni amb 192.168.10.0/24.

Nota: els rangs secundaris es poden donar en la creació amb --secondary-range o afegir-se després amb --add-secondary-ranges.

Solució 2

Punt 4: el resol Cloud NAT. La passarel·la alpinashop-nat-euw1 ja cobreix sn-datos-euw1, de manera que la VM, sense IP pública, surt a internet per instal·lar des de PyPI. A més, per descarregar del bucket alpinashop-catalogo o escriure a BigQuery no farà servir NAT, sinó Private Google Access, que està actiu a la subxarxa.

Quant a "només la Lucía i la Marta": el tallafoc no distingeix persones. Aquesta part es resol amb IAM donant roles/iap.tunnelResourceAccessor i roles/compute.osLogin únicament als grups corresponents; es veu a 03-04.

Solució 3

Per ordre de probabilitat:

1. Falta la regla de tallafoc per als rangs de comprovació d'estat. És la causa més freqüent amb diferència. La comprovació s'origina a 130.211.0.0/22 i 35.191.0.0/16, no a internet ni a la subxarxa.

2. L'etiqueta de xarxa no coincideix. La regla apunta a web-catalogo però la plantilla d'instància del MIG no aplica aquesta etiqueta a les màquines noves.

3. La comprovació apunta a un port o ruta equivocats. L'aplicació escolta al 8080 i exposa /salud, però la comprovació està configurada al 80 o a /.

Eina transversal: els registres de tallafoc de fw-deny-all-ingress mostraran els intents denegats des de 35.191.0.0/16 si la causa és la primera, i la prova de connectivitat del Network Intelligence Center confirma la regla exacta que bloqueja.

AlpinaShop ja té una xarxa de veritat. Has entès la propietat que defineix la xarxa de Google —la VPC és global, les subxarxes són regionals— i per què això simplifica arquitectures que en altres proveïdors exigeixen malabars. Has descartat la xarxa default amb arguments i has creat alpinashop-vpc en mode personalitzat, amb encaminament global i un pla d'adreçament documentat que reserva 10.10.0.0/16 per a producció, deixa forat per créixer i no xoca amb l'oficina ni amb alpinashop-dev.

Sobre aquesta xarxa has creat sn-web-euw1 (10.10.0.0/24) i sn-datos-euw1 (10.10.1.0/24), amb rangs secundaris gke-pods (10.20.0.0/16) i gke-servicios (10.21.0.0/20) perquè alpinashop-cluster faci servir xarxa nativa de VPC i els seus pods tinguin adreces reals. Has reservat la IP global alpinashop-lb-ip per al balancejador que construïm ara mateix i la IP alpinashop-nat-ip perquè la passarel·la de pagament pugui autoritzar una adreça de sortida estable.

Has après el model de tallafoc complet —stateful, distribuït, prioritat on guanya el número menor, quatre regles implícites, selecció per etiqueta o per compte de servei— i has escrit el conjunt real d'AlpinaShop: HTTP i comprovacions d'estat només des de 130.211.0.0/22 i 35.191.0.0/16, SSH només des del rang d'IAP 35.235.240.0/20, PostgreSQL només des del compte de servei sa-catalogo-web, i una denegació explícita amb registre que t'ensenya què està trucant a la porta. I saps per què 0.0.0.0/0 al 22 no és una comoditat sinó un incident pendent.

Finalment, les màquines ja no necessiten IP pública: Cloud NAT els dona sortida controlada amb una IP estàtica coneguda, Private Google Access les porta a les APIs de Google sense trepitjar internet, l'accés privat a serveis ha posat alpinashop-pedidos en una IP privada del rang 10.30.0.0/20, i els VPC Flow Logs converteixen els problemes de xarxa en consultes de registre en lloc de conjectures.

La xarxa està llesta, però el catàleg encara se serveix per la IP d'una màquina. A la lliçó següent, 03-02, Balanceig de càrrega al núvol, posem al davant un balancejador HTTP(S) extern global: una única adreça anycast que atén des del punt de presència més proper a cada client europeu, reparteix el trànsit entre les instàncies del MIG alpinashop-web-mig, serveix les imatges directament des del bucket alpinashop-catalogo mitjançant un mapa d'URL, i comprova la salut dels backends per aquesta ruta /salud que ja hem autoritzat al tallafoc. Totes les peces de xarxa que acabem de col·locar existeixen precisament perquè aquest balancejador funcioni a la primera.