Conectar recursos en la nube de forma segura es una de las tareas más críticas al diseñar arquitecturas en Google Cloud Platform. Comprender cómo funcionan las VPC, el peering entre redes y las reglas de firewall marca la diferencia entre una infraestructura robusta y una vulnerable.
¿Cómo se comunican los recursos entre diferentes VPCs?
Cuando varios recursos viven en subredes distintas dentro de la misma VPC, pueden comunicarse entre sí sin problema, siempre que las reglas de firewall lo permitan [0:10]. Sin embargo, si los recursos pertenecen a dos VPCs diferentes, la comunicación no ocurre de forma automática.
Para resolver esto existe el VPC peering [0:30], un mecanismo que permite conectar dos VPCs distintas y habilitar la comunicación entre equipos seleccionados de cada red.
¿Qué es una shared VPC y por qué centralizar la gestión de red?
Cada VPC está asociada a un proyecto en GCP. Si una organización maneja múltiples proyectos, cada uno necesitará su propia VPC y una persona capacitada para administrarla [0:42]. Esto puede volverse complejo rápidamente.
La VPC compartida o shared VPC resuelve este problema [1:08]. Funciona así:
- Se crea un proyecto host que centraliza todos los recursos de red: subredes, rangos de IP y reglas de firewall.
- Otros proyectos de servicio consumen la conectividad que ofrece el proyecto host.
- El equipo de networking administra todo desde un solo punto.
Los beneficios son claros: centralización de la gestión, simplificación administrativa e incremento en la seguridad [1:42].
¿Cómo funcionan las reglas de firewall en GCP?
Las reglas de firewall definen qué equipos pueden o no comunicarse entre sí [1:50]. Para entender su estructura, es necesario conocer tres elementos fundamentales.
Primero, el equipo origen: se identifica mediante una dirección IP o una etiqueta (tag) [2:08]. Una etiqueta es simplemente una palabra descriptiva asignada a una máquina virtual. Por ejemplo, una VM con un servidor HTTP podría llevar la etiqueta HTTP-server, y todas las máquinas con esa etiqueta se identificarán como servidores web [2:30]. Otra VM podría tener la etiqueta contabilidad para señalar que pertenece a esa área [2:55].
Segundo, el equipo target: es la máquina a la que se aplica la regla de firewall [3:05].
Tercero, la dirección del tráfico:
- Ingress: tráfico de entrada hacia el equipo target [3:22].
- Egress: tráfico de salida desde el equipo target hacia un destino [3:42].
En cada regla se utiliza la acción allow para permitir o deny para rechazar la comunicación [3:18].
¿Cuáles son las reglas implícitas de firewall en una VPC custom?
Cuando creas una VPC personalizada (custom), GCP no genera reglas de firewall automáticamente [4:05]. Sin embargo, existen dos reglas implícitas que siempre están presentes:
- Todo el tráfico de salida hacia Internet está permitido. Si tu VM necesita descargar actualizaciones del sistema operativo al arrancar, podrá hacerlo sin configuración adicional [4:22].
- Todo el tráfico de entrada está rechazado. Si intentas conectarte por SSH a una VM con Linux, no podrás hacerlo hasta que definas una regla explícita que lo permita [4:38].
Estas dos reglas son fundamentales para comprender el comportamiento por defecto de cualquier VPC que crees en GCP [4:55]. Para modificar este comportamiento, debes crear reglas de firewall explícitas según las necesidades de tu arquitectura.
¿Has tenido la experiencia de configurar reglas de firewall tanto en equipos físicos como en GCP? Comparte tu experiencia y las diferencias que encontraste en la sección de comentarios.
