Semana 3 · Módulo 3 de 12

Redes en Google Cloud (I): VPC, firewall y balanceo de carga

Aprenderás a diseñar una VPC de nivel empresarial (subredes, direccionamiento, rutas, firewall, NAT, DNS) y a elegir el balanceador de carga, Cloud CDN y Cloud Armor adecuados. Las redes son una de las áreas más preguntadas del examen y la base de todo lo demás.

Reparto de la semana

Por qué importa

Casi todas las preguntas del examen tienen «red» en algún sitio, aunque no lo parezca. Una pregunta de GKE acaba dependiendo de rangos secundarios; una de migración, de si las subredes se solapan con el centro de datos; una de seguridad, de si la VM necesita IP pública o basta con Cloud NAT. Y el balanceo de carga es un clásico: te describen una aplicación («usuarios en todo el mundo», «TCP no HTTP», «hay que conservar la IP del cliente», «solo interno») y tienes que elegir el balanceador correcto entre una familia de más de diez variantes.

En la guía oficial esto cae en dos apartados:

• 1.3 (diseño de recursos de red): VPC, peering, firewalls, balanceadores, rutas, redes de contenedores, Shared VPC y Private Service Connect.
• 2.1 (configurar topologías de red): diseño de VPC y balanceo de carga, acceso a la nube, a Internet y a servicios adyacentes, y protección (firewalls, control de acceso).

Esta semana cubrimos todo lo que vive dentro de Google Cloud. La semana que viene conectarás esa red con el centro de datos, con otras nubes y con otras VPC (conectividad híbrida, Shared VPC, Private Service Connect).

La VPC: una red global

Una Virtual Private Cloud (VPC, nube privada virtual) es una red privada definida por software que vive dentro de un proyecto. La gran diferencia con otras nubes es esta:

• La VPC es un recurso global. No pertenece a ninguna región.
• Las subredes son recursos regionales. Cada subred está en una región y abarca todas las zonas de esa región.

Consecuencia práctica: dos VMs en europe-southwest1 (Madrid) y us-central1 (Iowa) dentro de la misma VPC se hablan por IP interna sin VPN, sin peering y sin configurar nada; el tráfico viaja por la red troncal de Google. En otras nubes necesitarías una red por región y conectarlas entre sí.

flowchart LR
  subgraph VPC["VPC prod (global)"]
    subgraph R1["europe-southwest1"]
      S1["subred app-mad 10.10.0.0/20"]
    end
    subgraph R2["europe-west1"]
      S2["subred app-bel 10.20.0.0/20"]
    end
    subgraph R3["us-central1"]
      S3["subred app-usa 10.30.0.0/20"]
    end
  end
  S1 <-->|"IP interna, red de Google"| S2
  S2 <--> S3

Otros datos que conviene tener claros:

• Una VM se conecta a la red mediante interfaces de red (NIC). Por defecto tiene una; puedes darle varias, pero cada NIC debe estar en una VPC distinta. Es el patrón de los appliances de red (cortafuegos de terceros con una pata «dentro» y otra «fuera»).
• Un proyecto puede tener varias VPC, pero dos VPC distintas están aisladas entre sí hasta que las conectas (peering, VPN, Network Connectivity Center… lo verás la semana que viene).
• La MTU por defecto de una VPC es 1460 bytes; se puede cambiar (hasta jumbo frames de 8896 bytes) si la aplicación lo necesita.

Modo automático frente a modo personalizado

Al crear una VPC eliges su modo de creación de subredes:

La red default que traen los proyectos nuevos es una VPC en modo automático con cuatro reglas de firewall ya creadas (default-allow-internal, default-allow-ssh, default-allow-rdp, default-allow-icmp, todas de entrada y con prioridad 65534). Es cómoda para experimentar, pero en una empresa se suele eliminar o impedir su creación con la política de organización compute.skipDefaultNetworkCreation: abre SSH y RDP a todo Internet y sus rangos 10.128.0.0/9 chocan fácilmente con redes on-premises.

Modo de enrutamiento dinámico

Cada VPC tiene además un modo de enrutamiento dinámico (dynamic routing mode), que afecta a las rutas que aprende Cloud Router por BGP (VPN, Interconnect):

• Regional (por defecto): las rutas aprendidas en una región solo las usan las VMs de esa región.
• Global: las rutas aprendidas en cualquier región se propagan a todas las regiones de la VPC.

Si tu VPN termina en Madrid y quieres que una VM en Bélgica llegue al centro de datos por ella, necesitas modo global. Es una pregunta típica y lo retomarás en el módulo 4.

Subredes y direccionamiento

Rangos primarios

Cada subred tiene un rango primario IPv4 (de ahí salen las IP internas de las VMs y de los balanceadores internos). Reglas importantes:

• Puedes usar rangos RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) y también otros rangos privados o incluso IP públicas «usadas de forma privada».
• El prefijo más largo permitido es /29 (8 direcciones).
• Google reserva 4 direcciones del rango primario: la de red, la del gateway por defecto (la segunda), la penúltima y la de broadcast. En un /24 tienes 252 utilizables.
• El rango primario se puede ampliar (gcloud compute networks subnets expand-ip-range) pero no reducir ni sustituir. Por eso conviene empezar con rangos razonables y dejar hueco libre al lado para crecer.
• Dentro de una VPC, y entre VPC que vayas a conectar, los rangos no pueden solaparse. Y tampoco deberían solaparse con el centro de datos ni con otras nubes si alguna vez vas a unirlos.

Rangos secundarios y alias IP

Una subred puede tener además rangos secundarios. De ellos se asignan alias IP (alias IP ranges): direcciones o bloques adicionales que se asocian a la NIC de una VM. Sirven para que los procesos o contenedores que corren dentro de la VM tengan su propia IP enrutable en la VPC, sin rutas estáticas.

El uso estrella es GKE: los nodos toman su IP del rango primario, los Pods de un rango secundario y los Services de otro (o de un rango gestionado por GKE). Lo ves en detalle en «Redes de contenedores en GKE», al final del módulo.

Subredes con propósito especial

Algunas subredes no son para VMs sino para servicios gestionados. Se identifican por su purpose:

• REGIONAL_MANAGED_PROXY / GLOBAL_MANAGED_PROXY: subred solo de proxy (proxy-only subnet). La necesitan los balanceadores basados en Envoy regionales o internos entre regiones (los proxies de Google toman IP de ahí).
• PRIVATE_SERVICE_CONNECT: para publicar servicios con Private Service Connect (módulo 4).
• PRIVATE_NAT: para Private NAT.

Direcciones IP: internas, externas, efímeras y estáticas

Cruza dos ejes:

Detalles que caen en preguntas:

• Una IP externa estática puede ser regional (para VMs, balanceadores regionales, Cloud NAT, VPN) o global (solo para los balanceadores globales externos, que usan una IP anycast).
• Puedes promover una IP efímera a estática sin cambiarla (útil si descubres tarde que la necesitabas fija).
• Coste (estimación a 30/09/2026, precios de red): una IP externa en uso por una VM estándar cuesta unos 0,005 USD/h; una IP estática reservada y sin usar, unos 0,01 USD/h (se cobra más a propósito, para que no acapares direcciones). Las IP asignadas a reglas de reenvío de balanceadores o usadas por túneles VPN no se cobran aparte.
• Buena práctica de seguridad: las VMs no deberían tener IP externa. Se entra por IAP (Identity-Aware Proxy) o bastión, se sale por Cloud NAT y se publica por un balanceador. Hay una política de organización (compute.vmExternalIpAccess) para prohibirlas.

Rutas: cómo decide la VPC a dónde va un paquete

Cada VPC tiene una tabla de rutas distribuida. No hay «routers» que gestionar: el enrutamiento lo hace la capa de virtualización de red de Google (Andromeda) en cada host. Las rutas pueden ser:

1. Rutas de sistema (system-generated):
   • Rutas de subred: una por cada rango de subred (primario y secundarios). Hacen que toda la VPC se alcance entre sí. No se pueden borrar mientras exista la subred.
   • Ruta por defecto 0.0.0.0/0 hacia el default internet gateway. Es la salida a Internet (y a las APIs de Google). Se puede borrar o sustituir, por ejemplo para forzar todo el tráfico por un cortafuegos o hacia on-premises.
2. Rutas estáticas personalizadas (custom static routes): las creas tú. El siguiente salto (next hop) puede ser una VM (appliance), una IP interna, un balanceador de red interno de paso (internal passthrough Network Load Balancer, para poner varios appliances en alta disponibilidad), un túnel de Classic VPN o el default internet gateway. Pueden aplicarse solo a VMs con determinadas etiquetas de red.
3. Rutas dinámicas (dynamic routes): las aprende y anuncia Cloud Router por BGP a través de HA VPN o Cloud Interconnect. Se actualizan solas cuando cambia la red remota.

Si varias rutas encajan con el destino, gana la más específica (prefijo más largo). A igual prefijo, decide la prioridad (menor número gana). Con varias rutas iguales de igual prioridad, el tráfico se reparte (ECMP).

Existen también las rutas basadas en políticas (policy-based routes), que deciden el siguiente salto según origen, destino y protocolo; su uso típico es mandar el tráfico a un grupo de appliances de inspección.

Firewall: reglas VPC y Cloud NGFW

El firewall en Google Cloud es distribuido: no es una caja por la que pasa el tráfico, sino reglas que se aplican en cada VM (en realidad, en el host que la ejecuta). Por eso filtra también el tráfico entre dos VMs de la misma subred.

El producto se llama hoy Cloud Next Generation Firewall (Cloud NGFW) y engloba tanto las reglas de firewall VPC clásicas como las políticas de firewall. Tiene tres niveles:

Enterprise lo verás con más detalle en el módulo 4 (protección de topologías). Aquí céntrate en las reglas.

Reglas de firewall VPC

Cada regla tiene:

• Dirección: entrada (ingress) o salida (egress). Una regla es de una sola dirección.
• Prioridad: de 0 a 65535; menor número = más prioridad. Por defecto 1000. Se aplica la primera regla que coincide (la de mayor prioridad); a igual prioridad, gana deny sobre allow.
• Acción: allow o deny.
• Destino (target), es decir, a qué VMs se aplica:
  • todas las instancias de la red;
  • las que tengan una etiqueta de red (network tag), p. ej. web;
  • las que usen una cuenta de servicio concreta.
• Origen (en entrada) o destino (en salida): rangos IP y, en entrada, también etiquetas o cuentas de servicio de origen.
• Protocolos y puertos (tcp:80,443, udp, icmp…).
• Registro (firewall rules logging), opcional, para auditar qué permite o bloquea cada regla.

Y tiene estas propiedades fundamentales:

• Con estado (stateful): si permites una conexión en un sentido, las respuestas vuelven solas. No hace falta la regla «de vuelta».
• Reglas implícitas: toda VPC tiene, con la prioridad más baja posible (65535), un deny de toda la entrada y un allow de toda la salida. No aparecen en la lista y no se pueden borrar, pero sí «tapar» con reglas de mayor prioridad.
• En una misma regla no puedes mezclar etiquetas de red y cuentas de servicio.
• Hay tráfico que siempre se permite (hacia el servidor de metadatos 169.254.169.254) y tráfico que siempre se bloquea (salida al puerto TCP 25 hacia IP externas, para evitar spam).

Un ejemplo típico de tres capas, sin nada abierto a Internet salvo el balanceador:

Políticas de firewall: red, regionales y jerárquicas

Las reglas VPC tienen un límite: se gestionan red a red. Cuando tienes decenas de proyectos, necesitas políticas de firewall (firewall policies), que agrupan reglas y se asocian a recursos:

• Políticas de firewall jerárquicas (hierarchical firewall policies): se asocian a la organización o a una carpeta y afectan a todas las VPC que cuelgan de ellas. Permiten que el equipo de seguridad central imponga reglas que los equipos de proyecto no pueden saltarse («bloquea todo el tráfico desde estos países», «permite siempre los sondeos de salud»). Además de allow y deny tienen la acción goto_next, que delega la decisión al siguiente nivel.
• Políticas de firewall de red globales (global network firewall policies): se asocian a una o varias VPC y aplican en todas las regiones.
• Políticas de firewall de red regionales (regional network firewall policies): igual, pero solo en una región.

Las políticas soportan secure tags (etiquetas de Resource Manager con control de IAM), objetos FQDN, geolocalización y Threat Intelligence, y son la forma recomendada hoy de gestionar el firewall a escala.

Orden de evaluación por defecto: primero las políticas jerárquicas (organización y después carpetas, de arriba abajo), luego las reglas de firewall VPC, luego las políticas de red (global y regional) y, al final, las reglas implícitas. Puedes invertir el orden entre reglas VPC y políticas de red (BEFORE_CLASSIC_FIREWALL), pero las jerárquicas siempre van primero.

flowchart TD
  P["Paquete hacia una VM"] --> H1["Política jerárquica de la organización"]
  H1 -->|"goto_next o sin coincidencia"| H2["Políticas jerárquicas de carpetas"]
  H2 -->|"goto_next o sin coincidencia"| V["Reglas de firewall VPC"]
  V -->|"sin coincidencia"| N["Políticas de red global y regional"]
  N -->|"sin coincidencia"| I["Reglas implícitas: deny entrada, allow salida"]
  H1 -->|"allow o deny"| F["Decisión final"]
  H2 -->|"allow o deny"| F
  V -->|"allow o deny"| F
  N -->|"allow o deny"| F

Salida sin IP pública: Cloud NAT y Private Google Access

Si las VMs no tienen IP externa, surgen dos necesidades: bajar parches de Internet y llamar a APIs de Google (Cloud Storage, BigQuery…). Cada una tiene su solución.

Cloud NAT

Cloud NAT permite que recursos sin IP externa inicien conexiones salientes hacia Internet usando unas pocas IP públicas compartidas. Características:

• Es software definido y distribuido: no hay VMs de NAT ni un aparato por el que pase el tráfico, así que no es cuello de botella ni punto único de fallo.
• Es regional y se configura sobre un Cloud Router de esa región. Necesitas una pasarela por región (por VPC) en la que tengas recursos.
• No permite conexiones entrantes no solicitadas; solo traduce las respuestas. Para publicar algo, usa un balanceador.
• Sirve para VMs de Compute Engine, nodos de GKE, Cloud Run (con salida directa a VPC o Serverless VPC Access) y otros.
• Las IP de NAT pueden asignarse automáticamente o manualmente (IP estáticas reservadas). Manual cuando un tercero necesita poner tus IP de salida en una lista blanca.
• Existe también Private NAT, para traducir entre redes privadas con rangos solapados (por ejemplo, dos VPC o una VPC y on-premises).

Coste (estimación a 30/09/2026, precios de Cloud NAT): unos 0,0014 USD/h por VM que use la pasarela (con tope a partir de 32 VMs, 0,044 USD/h), 0,045 USD por GiB procesado y 0,005 USD/h por cada IP de NAT, más la salida a Internet normal.

gcloud compute routers create nat-router \
  --network=vpc-lab --region=europe-southwest1

gcloud compute routers nats create nat-mad \
  --router=nat-router --region=europe-southwest1 \
  --nat-all-subnet-ip-ranges \
  --auto-allocate-nat-external-ips

Private Google Access

Private Google Access (PGA, acceso privado a Google) permite que VMs sin IP externa lleguen a las APIs y servicios de Google (Cloud Storage, BigQuery, Pub/Sub…) sin salir a Internet. Se activa por subred:

gcloud compute networks subnets update app-mad \
  --region=europe-southwest1 --enable-private-ip-google-access

Datos clave:

• No afecta a VMs que ya tienen IP externa (esas ya llegan a las APIs).
• Necesita una ruta hacia el default internet gateway para los rangos de Google (la ruta por defecto sirve) y que el firewall permita la salida.
• Hay dos nombres de dominio especiales con IP fijas: private.googleapis.com (199.36.153.8/30, la mayoría de APIs) y restricted.googleapis.com (199.36.153.4/30, solo APIs compatibles con VPC Service Controls). Se usan cuando quieres que el DNS resuelva las APIs a esas IP y controlar el camino exacto, sobre todo desde on-premises (Private Google Access para hosts on-premises, módulo 4).
• La alternativa moderna con IP propias de tu VPC es Private Service Connect para APIs de Google (módulo 4).

Cloud DNS

Cloud DNS es el servicio DNS gestionado de Google, autoritativo, con SLA de disponibilidad muy alto y anycast. Tipos de zona que debes conocer:

Además, cada VPC tiene DNS interno de Compute Engine automático: cada VM se resuelve por su nombre (vm1.europe-southwest1-a.c.PROYECTO.internal) sin hacer nada.

Para DNS híbrido (que on-premises resuelva nombres de la nube y al revés) se combinan zonas de reenvío con políticas de servidor DNS (DNS server policies) de entrada. Lo verás a fondo en el módulo 4; por ahora quédate con que las consultas que Cloud DNS reenvía salen del rango 35.199.192.0/19, que hay que permitir y anunciar hacia on-premises.

La seguridad de las zonas públicas se refuerza con DNSSEC, que Cloud DNS permite activar por zona.

Balanceo de carga: la familia completa

Cloud Load Balancing reparte el tráfico entre backends (VMs de un MIG, Pods de GKE mediante NEG, Cloud Run, buckets de Cloud Storage…). No son VMs que tú gestionas: son servicios distribuidos definidos por software que escalan solos.

Las tres preguntas que definen el balanceador

Toda la familia se ordena con tres preguntas:

1. ¿Capa 7 o capa 4?
   • Application Load Balancer (ALB): capa 7, HTTP y HTTPS (también HTTP/2 y gRPC). Entiende URL, cabeceras, cookies; puede enrutar por ruta (/api a un backend, /img a otro), terminar TLS, usar Cloud CDN y Cloud Armor con reglas WAF.
   • Network Load Balancer (NLB): capa 4, TCP, UDP y otros protocolos IP.
2. ¿Externo o interno? Si los clientes vienen de Internet (externo) o de dentro de la VPC o de redes conectadas (interno).
3. ¿Global o regional? Si los backends pueden estar en varias regiones con una única IP (global) o todo vive en una región (regional). Relacionado: ¿proxy o de paso?
   • Proxy: el balanceador termina la conexión del cliente y abre otra hacia el backend. El backend ve la IP del proxy (la del cliente llega en cabeceras como X-Forwarded-For en HTTP).
   • De paso (passthrough): el paquete llega al backend tal cual; el backend ve la IP original del cliente y responde directamente (direct server return). Solo existe en los NLB y siempre es regional.

Tabla de la familia

El «classic» es la generación anterior del ALB externo; para diseños nuevos se usa el global o el regional externo (los basados en Envoy tienen gestión de tráfico avanzada: traffic splitting, mirroring, reescrituras, reintentos…).

Árbol de decisión

flowchart TD
  A{"¿El tráfico es HTTP, HTTPS o gRPC?"} -->|Sí| B{"¿Clientes en Internet?"}
  A -->|"No: TCP, UDP u otro"| G{"¿Hay que conservar la IP del cliente o usar UDP, ESP o ICMP?"}
  B -->|Sí| C{"¿Usuarios o backends en varias regiones, o Cloud CDN?"}
  B -->|"No, clientes internos"| D{"¿Backends en varias regiones?"}
  C -->|Sí| E["Global external Application LB"]
  C -->|"No, todo en una región o requisito de residencia"| F["Regional external Application LB"]
  D -->|Sí| D1["Cross-region internal Application LB"]
  D -->|No| D2["Regional internal Application LB"]
  G -->|Sí| H{"¿Clientes en Internet?"}
  G -->|"No, basta un proxy TCP o TLS"| J{"¿Clientes en Internet?"}
  H -->|Sí| H1["External passthrough Network LB"]
  H -->|No| H2["Internal passthrough Network LB"]
  J -->|"Sí, global o con offload TLS"| J1["Global external proxy Network LB"]
  J -->|"Sí, en una región"| J2["Regional external proxy Network LB"]
  J -->|No| J3["Internal proxy Network LB, regional o cross-region"]

Tabla de decisión por palabras clave

Piezas de un Application Load Balancer

Para entender los labs y los comandos, conviene conocer los componentes (de fuera hacia dentro):

1. Regla de reenvío (forwarding rule): la IP y el puerto de entrada. Es lo que se cobra por horas.
2. Proxy de destino (target HTTP(S) proxy): termina la conexión; en HTTPS lleva el certificado (gestionado por Google o propio, a través de Certificate Manager).
3. Mapa de URL (URL map): reglas de enrutamiento por host y ruta.
4. Servicio de backend (backend service): agrupa backends, define la comprobación de estado (health check), el modo de balanceo, la afinidad de sesión, y es donde se activan Cloud CDN y Cloud Armor. Alternativamente, un backend bucket sirve contenido estático desde Cloud Storage.
5. Backends: grupos de instancias (MIG), NEG (network endpoint groups: zonales para Pods de GKE, serverless NEG para Cloud Run, internet NEG para orígenes externos, NEG de Private Service Connect…).

Las comprobaciones de estado salen de rangos de Google conocidos (la documentación actual lista 35.191.0.0/16 para los balanceadores basados en proxy; en material antiguo verás también 130.211.0.0/22). Si olvidas la regla de firewall que las permite, todos los backends aparecen como no saludables y el balanceador devuelve errores: es una de las causas de fallo más preguntadas.

Coste (estimación a 30/09/2026, precios de Cloud Load Balancing): las primeras 5 reglas de reenvío de un proyecto cuestan unos 0,025 USD/h en total (≈ 18 USD/mes) y cada regla adicional 0,01 USD/h, más el tráfico procesado (del orden de 0,008 USD/GiB) y la salida a Internet. Los balanceadores internos Envoy se cobran por instancias de proxy (mínimo 3 por regla, ≈ 0,075 USD/h). Una regla de reenvío olvidada cuesta dinero aunque no reciba tráfico.

Cloud CDN

Cloud CDN cachea contenido en la red perimetral de Google, cerca de los usuarios. Se activa en el servicio de backend o backend bucket de un global external Application LB (o del classic ALB); no es un producto independiente con su propia IP.

Conceptos que debes reconocer:

• Modos de caché: CACHE_ALL_STATIC (por defecto: cachea contenido estático típico), USE_ORIGIN_HEADERS (obedece las cabeceras Cache-Control del origen) y FORCE_CACHE_ALL (cachea todo; cuidado con contenido privado).
• Clave de caché (cache key): qué partes de la URL identifican un objeto (puedes ignorar parámetros de consulta para mejorar el acierto).
• URL y cookies firmadas (signed URLs/cookies): acceso temporal a contenido privado cacheado (p. ej. vídeos de pago).
• Invalidación de caché por ruta cuando publicas una versión nueva.
• Siempre usa el nivel de red Premium.

Resultado: menos latencia, menos carga en el origen y menos coste de salida (el tráfico servido desde caché tiene su propia tarifa).

Cloud Armor

Google Cloud Armor es el servicio de protección DDoS y WAF (web application firewall) de Google. Se aplica mediante políticas de seguridad (security policies) asociadas a los servicios de backend de los balanceadores externos (todos los Application LB externos, incluido el classic, y también el regional interno ALB, los proxy NLB externos globales y classic, y el external passthrough NLB para protección de red).

Qué hace:

• Protección DDoS L3/L4 siempre activa para los balanceadores externos proxy, sin configurar nada: absorbe ataques volumétricos y de protocolo en el borde de la red de Google.
• Reglas de capa 7 con prioridad (como el firewall, menor número = antes) y acciones allow, deny (403, 404, 502), redirigir o limitar:
  • por IP o rango (listas blancas y negras), por región geográfica del cliente, por cabeceras, rutas o cookies, con un lenguaje de reglas personalizado (CEL);
  • reglas WAF preconfiguradas basadas en OWASP ModSecurity Core Rule Set (CRS 3.3 y 4.x) contra inyección SQL, XSS, LFI, RFI, RCE…, con niveles de sensibilidad para ajustar falsos positivos. Ejemplo de expresión: evaluatePreconfiguredWaf('sqli-v422-stable', {'sensitivity': 1}) (dentro de una regla).
• Limitación de velocidad (rate limiting):
  • throttle: limita cada cliente a N peticiones por intervalo; el exceso recibe la acción de rechazo (p. ej. 429);
  • rate-based ban: si el cliente supera el umbral, lo bloquea durante un tiempo.
  • La clave puede ser la IP, una cabecera, una cookie, la ruta, el país, el ASN, la huella TLS, etc.
• Modo vista previa (preview): registra lo que haría una regla sin aplicarla. Imprescindible antes de activar WAF en producción.
• Gestión de bots con reCAPTCHA y listas de IP con nombre (named IP lists) de proveedores conocidos.
• Adaptive Protection: modelos de aprendizaje automático que detectan ataques DDoS de capa 7 y proponen reglas (con Cloud Armor Enterprise).

Niveles (estimación a 30/09/2026, precios de Cloud Armor):

gcloud compute security-policies create web-policy \
  --description="WAF basico"

gcloud compute security-policies rules create 1000 \
  --security-policy=web-policy \
  --expression="evaluatePreconfiguredWaf('sqli-v422-stable', {'sensitivity': 1})" \
  --action=deny-403

gcloud compute security-policies rules create 2000 \
  --security-policy=web-policy \
  --src-ip-ranges="*" \
  --action=throttle \
  --rate-limit-threshold-count=100 \
  --rate-limit-threshold-interval-sec=60 \
  --conform-action=allow \
  --exceed-action=deny-429 \
  --enforce-on-key=IP

gcloud compute backend-services update web-backend \
  --security-policy=web-policy --global

Niveles de servicio de red: Premium frente a Standard

Google Cloud ofrece dos Network Service Tiers para el tráfico con Internet:

Se puede fijar por proyecto (gcloud compute project-info update --default-network-tier=STANDARD) o por recurso (IP, regla de reenvío).

Redes de contenedores en GKE

En el módulo 2 viste GKE. Su red tiene tres rangos:

Esto es un clúster nativo de VPC (VPC-native cluster), basado en alias IP. Es el modo por defecto para clústeres nuevos, y Autopilot siempre es nativo de VPC. El modo antiguo, basado en rutas (routes-based), creaba una ruta estática por nodo y está desaconsejado.

Ventajas de VPC-native:

• Las IP de los Pods son enrutables en la VPC y en redes conectadas (peering, VPN, Interconnect) sin rutas adicionales.
• Las IP se reservan en la VPC antes de crear Pods, así que no hay conflictos.
• Puedes escribir reglas de firewall para los rangos de Pods.
• Los balanceadores pueden enviar tráfico directamente a los Pods mediante NEG (container-native load balancing), sin pasar por los nodos.

Dimensionamiento: el rango de Pods limita el número de nodos. Con /24 por nodo, un rango secundario /16 da para 256 nodos como mucho. Si te quedas corto, GKE permite añadir rangos de Pods adicionales no contiguos (discontiguous multi-Pod CIDR). En un diseño de examen, dimensiona los rangos secundarios pensando en el crecimiento y sin solapar con on-premises.

Otras piezas de red de GKE que pueden aparecer:

• Clúster privado: los nodos solo tienen IP internas (necesitan Cloud NAT para salir a Internet) y el plano de control se expone de forma restringida.
• Gateway API / Ingress: crean automáticamente Application Load Balancers a partir de objetos de Kubernetes.
• Network policies (con GKE Dataplane V2): firewall entre Pods dentro del clúster.

Trampas típicas del examen

• La VPC es global y la subred regional. Si una opción propone «crear una VPC por región y unirlas con VPN» para comunicar regiones del mismo proyecto, sobra: una única VPC ya lo hace.
• Auto mode en producción casi nunca es la respuesta correcta; y dos VPC auto mode no se pueden unir por peering porque sus rangos se solapan.
• Prioridad del firewall: el número más bajo gana. Una regla deny con prioridad 1000 pierde frente a un allow con prioridad 900.
• Reglas implícitas: la entrada está denegada por defecto y la salida permitida. Si piden «bloquear la salida a Internet salvo a X», necesitas un deny de salida de baja prioridad y un allow de salida con más prioridad.
• Etiquetas frente a cuentas de servicio: control fuerte y separación de funciones → cuentas de servicio o secure tags.
• Reglas para toda la organización → política de firewall jerárquica, no reglas VPC ni políticas de organización.
• Health checks bloqueados → backends «unhealthy». Falta la regla de firewall para los rangos de sondeo de Google.
• «VM sin IP pública que necesita salir a Internet» → Cloud NAT; «a APIs de Google» → Private Google Access. Cloud NAT no acepta conexiones entrantes.
• UDP o conservar la IP del cliente → balanceador de paso (passthrough). Un Application LB nunca vale para UDP.
• Cloud CDN solo con el Application LB externo global (o classic) y nivel Premium.
• Bloquear países, SQLi, XSS o limitar peticiones en una web tras un balanceador → Cloud Armor, no firewall VPC.
• Standard tier abarata la salida pero no admite recursos globales.
• IP estáticas reservadas sin usar cuestan más que las usadas; una regla de reenvío olvidada factura aunque no haya tráfico.
• GKE sin IP para Pods → rangos secundarios mal dimensionados.

Resumen

• La VPC es global y las subredes regionales; usa modo personalizado en producción con un plan de direccionamiento sin solapes.
• Las subredes tienen rango primario (ampliable, nunca reducible, 4 IP reservadas) y rangos secundarios para alias IP (Pods de GKE).
• El enrutamiento combina rutas de subred, ruta por defecto, estáticas y dinámicas (Cloud Router con BGP); gana el prefijo más largo y después la prioridad.
• El firewall es distribuido y con estado: prioridad 0-65535 (menor gana), entrada denegada y salida permitida por defecto; destinos por etiqueta o, mejor, por cuenta de servicio. A escala: políticas de firewall jerárquicas, globales y regionales (Cloud NGFW Essentials, Standard y Enterprise).
• Cloud NAT da salida a Internet sin IP públicas; Private Google Access da acceso a APIs de Google sin salir a Internet.
• Cloud DNS: zonas públicas, privadas, de reenvío y de peering; políticas de servidor para DNS híbrido.
• Balanceadores: Application (L7, HTTP) o Network (L4); externo o interno; global o regional; proxy o de paso (conserva IP del cliente, UDP).
• Cloud CDN en el ALB externo global; Cloud Armor para DDoS, WAF (OWASP CRS), geobloqueo y rate limiting.
• Premium (red de Google, global, 99,99 %) frente a Standard (Internet pública, regional, más barato).
• GKE VPC-native: nodos en el rango primario, Pods y Services en secundarios; dimensiónalos pensando en el crecimiento.

Practica lo aprendido

Documentación oficial para ampliar

• VPC networks
• Subnets
• VPC firewall rules
• Cloud NGFW overview
• Cloud NAT overview
• Private Google Access
• Cloud DNS zones overview
• Cloud Load Balancing overview
• Cloud Armor overview
• Network Service Tiers overview
• VPC-native clusters (GKE)
• Network pricing