Unidad 2.3: Equilibrio de carga y seguridad como código

Introducción

La pila de red de TaskBoard de la Unidad 2.2 tiene tres niveles interconectados: una LAN pública, una LAN de aplicaciones y una LAN de base de datos. Los servidores de API son accesibles en la LAN de aplicaciones, pero aún no hay ningún componente que los frontee, y no hay nada que filtre el tráfico que llega a sus NIC. En esta unidad, provisionará el borde.

Colocará un Managed Application Load Balancer delante de la API, distribuyendo las solicitudes HTTP entre los servidores de aplicaciones mediante enrutamiento basado en rutas. Verá cuándo un Network Load Balancer es la herramienta adecuada, y restringirá cada nivel con reglas de Network Security Group. La lección importante específica de IONOS CLOUD aquí es dónde se aplican realmente las reglas de seguridad: los NSG se aplican a nivel de NIC del servidor, nunca al balanceador de carga y nunca a los nodos de Managed Kubernetes. Si se equivoca en esto, pasará horas preguntándose por qué sus reglas de firewall no tienen efecto en el tráfico que llega a través del ALB. Todo en esta unidad es código: recursos de Terraform y las llamadas a la Cloud API subyacentes.

1. Application Load Balancer como código

El recurso ionoscloud_application_loadbalancer aprovisiona un Load Balancer de capa 7 que termina HTTP y HTTPS y enruta según atributos a nivel de aplicación. El ALB se sitúa entre una LAN de listener, donde los clientes lo alcanzan, y una LAN de destino, donde se encuentran sus backends. Para la API de TaskBoard, la LAN de listener es la LAN pública y la LAN de destino es la LAN de la aplicación.

Un ALB se compone de tres tipos de recursos: el propio Load Balancer, uno o más grupos de destino que registran los destinos de backend, y reglas de reenvío que asocian un listener con dichos destinos. Un grupo de destino es una agrupación lógica de destinos registrados, donde cada destino es cualquier objeto con una dirección IP en su VDC, como una VM u otro Load Balancer. Puede reutilizar el mismo grupo de destino en múltiples reglas de reenvío.

1.1 Aprovisionamiento del Load Balancer y del grupo de destino

Comience con el Load Balancer y un grupo de destino. Cada destino se registra con una IP, un puerto y un peso. El rango del peso del destino es 1 - 256, y se utiliza para enviar proporcionalmente más tráfico a backends de mayor tamaño.

resource "ionoscloud_application_loadbalancer" "taskboard_api" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-api-alb"
  listener_lan  = ionoscloud_lan.public.id
  target_lan    = ionoscloud_lan.app.id
  ips           = [ionoscloud_ipblock.alb_ip.ips[0]]
}

resource "ionoscloud_target_group" "api_targets" {
  name      = "taskboard-api-tg"
  algorithm = "ROUND_ROBIN"
  protocol  = "HTTP"

  targets {
    ip                 = ionoscloud_server.api_1.nics[0].ips[0]
    port               = 8080
    weight             = 10
    health_check_enabled = true
  }
  targets {
    ip                 = ionoscloud_server.api_2.nics[0].ips[0]
    port               = 8080
    weight             = 10
    health_check_enabled = true
  }
}

Un ALB público requiere una IP pública reservada, por lo que el argumento ips hace referencia a una ionoscloud_ipblock. Los algoritmos de balanceo de carga admitidos son Round Robin, Least Connections, Random y Source IP, siendo Round Robin el predeterminado.

1.2 Reglas de reenvío y listeners

Las reglas de reenvío definen cómo se distribuye el tráfico del cliente hacia los destinos, y es posible crear más de una regla para el mismo balanceador de carga. Una regla de reenvío asocia una IP y un puerto de listener con una regla HTTP que reenvía las solicitudes coincidentes a un grupo de destinos.

resource "ionoscloud_application_loadbalancer_forwardingrule" "api_http" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  application_loadbalancer_id = ionoscloud_application_loadbalancer.taskboard_api.id
  name          = "taskboard-api-fwd"
  protocol      = "HTTP"
  listener_ip   = ionoscloud_ipblock.alb_ip.ips[0]
  listener_port = 80

  http_rules {
    name           = "forward-api"
    type           = "FORWARD"
    target_group   = ionoscloud_target_group.api_targets.id
  }
}

El ALB admite los protocolos HTTP y HTTPS sobre HTTP1 y HTTP2. Además de la reenvío simple basado en rutas, los tipos de enrutamiento incluyen los basados en nombre de host, cadena de consulta, encabezado, método, cookie, IP de origen, redirección de URL y respuestas fijas estáticas. Un ALB en su contrato puede tener de 1 a 10 listeners, y puede aprovisionar hasta 5 ALBs por contrato.

1.3 TLS, WebSocket y gRPC

El ALB admite la descarga de TLS, por lo que termina las conexiones HTTPS y reenvía HTTP plano a sus backends, eliminando el manejo de certificados de sus servidores de aplicación. Se admite SNI, lo que permite que un solo listener atienda múltiples certificados por nombre de host. Tanto WebSocket como gRPC están admitidos, por lo que el mismo ALB da servicio a una API REST y a un punto de extremo de streaming sin necesidad de un proxy separado. La llamada de API cruda para crear un ALB con capacidad para WebSocket apunta a la colección applicationloadbalancers:

curl -X POST \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer '"$IONOS_TOKEN" \
  https://api.ionos.com/cloudapi/v6/datacenters/$DC_ID/applicationloadbalancers \
  -d '{"properties":{"name":"alb-websocket","listenerLan":1,"targetLan":2,"ips":["1.2.3.4"]}}'

2. Network Load Balancer como código

Cuando se necesita un rendimiento L4 bruto y no se requiere enrutamiento a nivel de aplicación, el recurso ionoscloud_networkloadbalancer aprovisiona un Load Balancer de la capa 4. El NLB opera en la capa 4 del modelo OSI y distribuye el tráfico TCP entre destinos sin inspeccionar la carga útil.

El NLB tiene una única interfaz de listener que puede admitir múltiples IPs con diferentes reglas de reenvío. Un NLB público está expuesto a la internet y acepta conexiones de clientes directamente desde la internet, actuando como un dispositivo de borde para el tráfico norte-sur. Sus algoritmos de balanceo de carga son el mismo conjunto que los del ALB: Round Robin, Least Connections, Random y Source IP.

2.1 Aprovisionamiento de un NLB con reglas de reenvío

resource "ionoscloud_networkloadbalancer" "taskboard_nlb" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-nlb"
  listener_lan  = ionoscloud_lan.public.id
  target_lan    = ionoscloud_lan.app.id
  ips           = [ionoscloud_ipblock.nlb_ip.ips[0]]
}

resource "ionoscloud_networkloadbalancer_forwardingrule" "tcp" {
  datacenter_id          = ionoscloud_datacenter.taskboard.id
  networkloadbalancer_id = ionoscloud_networkloadbalancer.taskboard_nlb.id
  name          = "taskboard-tcp-fwd"
  algorithm     = "SOURCE_IP"
  protocol      = "TCP"
  listener_ip   = ionoscloud_ipblock.nlb_ip.ips[0]
  listener_port = 5432

  targets {
    ip     = ionoscloud_server.db_1.nics[0].ips[0]
    port   = 5432
    weight = 1
  }

  health_check {
    client_timeout = 50000
    connect_timeout = 5000
    target_timeout  = 50000
    retries         = 3
  }
}

El conjunto de protocolos del NLB es solo TCP; no se admite UDP y no se admiten las comprobaciones de estado HTTP, por lo que la comprobación del estado se basa en TCP. La persistencia de sesión en el NLB utiliza la afinidad por IP de origen: una sesión de cliente permanece en el mismo destino mientras sus sesiones TCP sigan activas. El peso predeterminado del destino es 1, con un máximo de 256, y el valor predeterminado de la comprobación del estado es de 3 reintentos. Puede aprovisionar hasta 5 NLBs por contrato.

2.2 Elección entre ALB y NLB

La decisión se basa en la capa que su enrutamiento necesita inspeccionar. La siguiente tabla resume las dos opciones para las decisiones en tiempo de código:

Elija el ALB cuando enrute por ruta de URL, host o cabecera, o cuando desee que el equilibrador de carga termine TLS. La API de TaskBoard utiliza un ALB para que /api/tasks y /api/health puedan ser enrutados y que TLS se termine en el borde. Elija el NLB para servicios TCP que no son HTTP, cuando desee una distribución L4 con sobrecarga mínima y la aplicación gestione sus propios asuntos de protocolo.

3. Network Security Groups como código

Un Network Security Group es un firewall con estado que se adjunta a sus VM y NIC. La regla específica de IONOS CLOUD que rige todo en esta sección: los NSG se vinculan a nivel de servidor-NIC. No se aplican al Managed ALB o NLB, y los nodos de los pools de nodos de Managed Kubernetes están excluidos de los NSG. Usted protege los backends equilibrados de carga escribiendo reglas en las NIC de los backends, no en el equilibrador de carga.

La acción predeterminada de un NSG es denegar todo, por lo que el tráfico se bloquea a menos que una regla explícita lo permita. Las reglas tienen una dirección, ya sea INGRESS o EGRESS, y se admiten ambas direcciones. Los protocolos admitidos son TCP, UDP, ICMP, ICMPv6, GRE, VRRP, ESP, AH y ANY.

3.1 Adjuntar NSG y escribir reglas

La granularidad de adjunción es por VM, lo que cubre todas las NIC de esa VM, o por NIC para un control granular. Cuando una VM es miembro de un NSG, todas las NIC de la VM heredan implícitamente las reglas del firewall. Cada NIC puede tener hasta 10 NSG, un VDC puede contener hasta 200 NSG y cada NSG puede contener hasta 100 reglas.

resource "ionoscloud_nsg" "app_tier" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-app-nsg"
  description   = "App tier: allow ALB to API port only"
}

resource "ionoscloud_nsg_firewallrule" "allow_api_from_app_lan" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  nsg_id        = ionoscloud_nsg.app_tier.id
  protocol      = "TCP"
  name          = "allow-api-8080"
  type          = "INGRESS"
  source_ip     = "10.0.1.0/24"
  port_range_start = 8080
  port_range_end   = 8080
}

Dado que el firewall es con estado, solo se escribe la regla de entrada para un servicio TCP entrante; el tráfico de respuesta se permite automáticamente sin necesidad de una regla de salida correspondiente.

3.2 La API sin procesar y las propiedades de las reglas

Bajo los recursos de Terraform, un NSG es la entidad de la API security-group y cada regla es una entidad firewall-rule. Solo los administradores de contrato, los propietarios y los usuarios con permisos sobre el VDC correspondiente pueden crear y gestionar NSGs a través de la API. La solicitud POST para agregar una regla se dirige al grupo de seguridad en un centro de datos:

curl -X POST \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer '"$IONOS_TOKEN" \
  https://api.ionos.com/cloudapi/v6/datacenters/$DC_ID/securitygroups/$NSG_ID/rules \
  -d '{"properties":{"name":"allow-api-8080","protocol":"TCP","type":"INGRESS","sourceIp":"10.0.1.0/24","portRangeStart":8080,"portRangeEnd":8080}}'

Los nombres de las propiedades de la regla son name, protocol, sourceMac, ipVersion, sourceIp, targetIp, portRangeStart, portRangeEnd, icmpCode, icmpType y type. Un NSG predeterminado contiene 4 reglas predefinidas: permitir todo el tráfico saliente IPv4, permitir todo el tráfico saliente IPv6, permitir el tráfico entrante IPv4 solo desde 10.0.0.0/24, y permitir el tráfico entrante IPv6 solo desde el CIDR /56 asignado al centro de datos. El efecto neto es que se permite todo el tráfico saliente, mientras que el tráfico entrante se bloquea, excepto para los rangos permitidos explícitamente.

4. Protección de la capa con equilibrador de carga

La consecuencia arquitectónica fundamental de que las NSG se vinculen a las NIC es que el ALB no es un límite de seguridad que pueda configurarse con reglas de firewall. El tráfico que el ALB reenvía a su backend llega a la NIC del backend, y es en esa NIC donde se produce el filtrado. Por lo tanto, debe escribir sus reglas de NSG para permitir únicamente la entrada del tráfico del equilibrador de carga.

Para la capa de la aplicación TaskBoard, el ALB se encuentra en la LAN del listener (pública) y reenvía el tráfico hacia la LAN de la aplicación. Las NIC de los servidores de la aplicación deben aceptar TCP en el puerto de la API únicamente desde la subred de la LAN de la aplicación, y rechazar todo lo demás. Las NIC de la capa de BD deben aceptar tráfico de PostgreSQL únicamente desde la LAN de la aplicación, nunca desde la LAN pública.

4.1 Reglas de aislamiento entre capas

# DB tier: PostgreSQL reachable only from the app subnet
resource "ionoscloud_nsg" "db_tier" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-db-nsg"
}

resource "ionoscloud_nsg_firewallrule" "allow_pg_from_app" {
  datacenter_id    = ionoscloud_datacenter.taskboard.id
  nsg_id           = ionoscloud_nsg.db_tier.id
  protocol         = "TCP"
  name             = "allow-pg-from-app"
  type             = "INGRESS"
  source_ip        = "10.0.1.0/24"
  port_range_start = 5432
  port_range_end   = 5432
}

Dado que db_tier es un NSG personalizado que no tiene reglas propias más allá de la que acaba de escribir, no recibe las reglas predeterminadas predefinidas por la plataforma (estas se aplican únicamente al NSG predeterminado propio del VDC); esta pila le proporciona tráfico entrante de PostgreSQL solo desde la subred de aplicaciones, y debe agregar una regla de tráfico saliente explícita en db_tier si el servidor de base de datos requiere cualquier conectividad saliente (por ejemplo, DNS, NTP o aplicación de parches). No existe ninguna regla que mencione la LAN pública, por lo que la base de datos es inalcanzable desde internet por diseño.

4.2 Adjuntar el NSG a las NIC de los servidores de backend

El NSG solo surte efecto una vez que se adjunta a las NIC que debe proteger. Adjunte el NSG de la capa de aplicaciones a las NIC de los servidores de API y el NSG de la capa de base de datos a las NIC de los servidores de base de datos. Dado que la membresía se hereda por todas las NIC de una VM miembro, puede adjuntarlo a nivel de VM cuando un servidor tiene una sola NIC relevante.

# NSG membership is an argument on the resource being protected, not a separate
# resource. Add it to the existing API server declarations.
resource "ionoscloud_server" "api_1" {
  # ... existing arguments unchanged
  security_groups_ids = [ionoscloud_nsg.app_tier.id]
}

resource "ionoscloud_server" "api_2" {
  # ... existing arguments unchanged
  security_groups_ids = [ionoscloud_nsg.app_tier.id]
}

El resultado es una postura de defensa en profundidad escrita por completo en Terraform: el ALB distribuye y termina TLS, mientras que los NSGs en las NIC de los servidores de backend garantizan que solo el tráfico previsto llegue a cada nivel.

Tarjeta rápida de referencia de la API

Puntos finales de la API clave para el equilibrio de carga y la seguridad:

URL base: https://api.ionos.com/cloudapi/v6 Autenticación: Authorization: Bearer <token>

Laboratorio de código

Objetivo: Aprovisionar un ALB para la API de TaskBoard con Terraform, agregar reglas de NSG a las capas de aplicación y de base de datos, y verificar el enrutamiento y el aislamiento.

Requisitos previos:

• Cuenta de IONOS CLOUD con token de API (IONOS_TOKEN exportado)
• Terraform con el proveedor ionoscloud configurado
• La pila de red de TaskBoard de la Unidad 2.2 ya aplicada (centro de datos, LANs, servidores)

Paso 1: Reservar una IP pública para el ALB

resource "ionoscloud_ipblock" "alb_ip" {
  location = "de/fra"
  size     = 1
  name     = "taskboard-alb-ip"
}

Salida esperada:

ionoscloud_ipblock.alb_ip: Creation complete after 8s [id=...]

Paso 2: Agregar el balanceador de carga y el grupo de destinos

terraform apply -target=ionoscloud_application_loadbalancer.taskboard_api \
  -target=ionoscloud_target_group.api_targets

Salida esperada:

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Paso 3: Agregar la regla de reenvío

terraform apply -target=ionoscloud_application_loadbalancer_forwardingrule.api_http

Salida esperada:

ionoscloud_application_loadbalancer_forwardingrule.api_http: Creation complete

Paso 4: Crear y adjuntar el NSG de la capa de aplicación

terraform apply \
  -target=ionoscloud_nsg.app_tier \
  -target=ionoscloud_nsg_firewallrule.allow_api_from_app_lan \
  -target=ionoscloud_server.api_1 \
  -target=ionoscloud_server.api_2

Salida esperada:

Apply complete! Resources: 2 added, 2 changed, 0 destroyed.

Paso 5: Crear el NSG de la capa de BD con la regla de aislamiento

terraform apply -target=ionoscloud_nsg.db_tier \
  -target=ionoscloud_nsg_firewallrule.allow_pg_from_app

Salida esperada:

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Paso 6: Verifique que el ALB enrute hacia la API

curl -i http://$(terraform output -raw alb_ip)/api/health

Salida esperada:

HTTP/1.1 200 OK
{"status":"ok"}

Paso 7: Verificar el aislamiento de la base de datos desde el lado público

nc -zv -w 5 $(terraform output -raw db_public_check) 5432

Salida esperada:

nc: connect to ... port 5432 (tcp) timed out: Operation now in progress

Lista de verificación de validación:

• [ ] ALB devuelve 200 en /api/health a través de la IP pública reservada
• [ ] Las NIC de la aplicación aceptan TCP 8080 solo desde la subred de la aplicación
• [ ] PostgreSQL en la capa de BD no es accesible desde fuera de la subred de la aplicación

Limpieza:

terraform destroy \
  -target=ionoscloud_application_loadbalancer_forwardingrule.api_http \
  -target=ionoscloud_application_loadbalancer.taskboard_api \
  -target=ionoscloud_target_group.api_targets \
  -target=ionoscloud_nsg.app_tier \
  -target=ionoscloud_nsg.db_tier \
  -target=ionoscloud_ipblock.alb_ip

Errores comunes

Errores de desarrollo a evitar con el equilibrio de carga y la seguridad en IONOS CLOUD:

1. Intentar adjuntar un NSG al equilibrador de carga

   • Problema: Usted escribe reglas de firewall esperando que filtren el tráfico en el ALB, pero no tienen ningún efecto.
   • Por qué ocurre: Los NSG se vinculan únicamente a nivel de NIC del servidor. No se aplican al ALB administrado ni al NLB, y los nodos de los grupos de nodos de Managed Kubernetes quedan excluidos por completo.
   • Solución: Escriba las reglas en las NIC de los servidores de backend. Permita solo el tráfico reenviado por el equilibrador de carga y aísle cada capa en sus propias NIC.

2. Escribir reglas de salida para servicios entrantes

   • Problema: Usted agrega una regla de entrada para TCP 8080 y una regla de salida correspondiente para la respuesta, y luego el tráfico se comporta de manera inconsistente o usted abre en exceso el NSG.
   • Por qué ocurre: El NSG de IONOS CLOUD es un firewall con estado, por lo que el tráfico de respuesta para una conexión entrante permitida se autoriza automáticamente.
   • Solución: Escriba solo la regla de entrada para un servicio entrante. Reserve las reglas de salida para las conexiones que su servidor inicia.

3. Olvidar que el ALB requiere una IP pública reservada

   • Problema: terraform apply falla al crear un ALB público porque no se proporciona ninguna IP pública utilizable.
   • Por qué ocurre: Un ALB público requiere una IP pública reservada, proporcionada mediante el argumento ips.
   • Solución: Provisione primero un ionoscloud_ipblock y haga referencia a ionoscloud_ipblock.alb_ip.ips[0] tanto en el equilibrador de carga como en el listener de la regla de reenvío.

Resumen

Ahora puede colocar un equilibrador de carga administrado frente a un nivel y proteger ese nivel por completo mediante código. El ALB gestiona la enrutación de la capa 7, la descarga de TLS y protocolos como WebSocket y gRPC, mientras que el NLB le ofrece una distribución TCP de la capa 4 con una sobrecarga mínima. Los Network Security Groups aplican un filtrado con estado, de denegar todo, por NIC, y usted protege los servidores de origen equilibrados por carga escribiendo reglas en las NIC de los servidores de origen, ya que el propio equilibrador de carga no es un destino de NSG.

Para TaskBoard, la API ahora se encuentra detrás de un ALB en la LAN pública, las NIC de la aplicación solo aceptan tráfico de API reenviado desde la subred de la aplicación, y la base de datos es accesible únicamente desde el nivel de la aplicación. La siguiente unidad aprovisiona el nivel de almacenamiento en el que dependen esos servidores.

Puntos clave:

• El ALB se compone de tres recursos: ionoscloud_application_loadbalancer, ionoscloud_target_group y ionoscloud_application_loadbalancer_forwardingrule
• Elija el ALB para la enrutación de aplicaciones HTTP y HTTPS y la descarga de TLS; elija el NLB para la distribución TCP de la capa 4
• Los NSG se vinculan únicamente a nivel de NIC del servidor, nunca al ALB, al NLB o a los nodos de Managed Kubernetes
• Los NSG tienen como valor predeterminado denegar todo y son con estado, por lo que solo debe escribir reglas de entrada para los servicios entrantes
• Proteja un nivel equilibrado por carga filtrando en las NIC de los servidores de origen y aislando cada nivel con su propio NSG

Terminología importante:

• Grupo de destinos: Un agrupamiento lógico de destinos registrados (IP, puerto, peso) al que un ALB distribuye el tráfico; reutilizable entre reglas de reenvío.
• Regla de reenvío: Una regla que vincula una IP y un puerto de un oyente con destinos, definiendo cómo el equilibrador de carga distribuye el tráfico del cliente.
• Oyente: La interfaz orientada al cliente de un equilibrador de carga que acepta conexiones en una IP expuesta y un puerto configurado.
• Network Security Group (NSG): Un firewall con estado, de denegar todo, adjunto por VM o por NIC, que admite hasta 100 reglas.
• Descarga de TLS: Terminar HTTPS en el ALB y reenviar HTTP plano a los servidores de origen, eliminando el manejo de certificados de los servidores de aplicación.

Próximos pasos

Siga aprendiendo: Unidad 2.4: Almacenamiento como código

Temas relacionados:

• Unidad 2.2: Red y conectividad como código
• Unidad 5.2: Automatización de seguridad