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

Introducción

Su pila de red TaskBoard de la Unidad 2.2 tiene tres niveles conectados: un LAN público, un LAN de aplicación y un LAN de base de datos. Los servidores API son accesibles en el LAN de aplicación, pero nada los frente aún, y nada filtra el tráfico que llega a sus NIC. En esta unidad, usted provisiona el borde.

Usted colocará un Managed Application Load Balancer delante de los servidores API, distribuyendo las solicitudes HTTP a través de los servidores de aplicación con enrutamiento basado en ruta. Usted verá cuándo un Load Balancer de red es la herramienta adecuada en su lugar, y usted bloqueará cada nivel con reglas de Grupo de Seguridad de Red. La lección importante específica de IONOS aquí es dónde se une realmente la seguridad: las reglas de NSG se aplican al nivel de servidor-NIC, nunca al Load Balancer y nunca a los nodos Managed Kubernetes. Si lo hace mal, usted pasará horas preguntándose por qué sus reglas Firewall no tienen efecto en el tráfico que llega a través del ALB. Todo en esta unidad es código: recursos Terraform y las llamadas crudas a Cloud API subyacentes.

1. Aplicación Load Balancer como código

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

Un ALB se construye a partir de tres tipos de recursos: el propio Load Balancer, uno o más grupos de destino que registran objetivos de backend, y reglas de reenvío que asignan un listener a esos objetivos. Un grupo de destino es un grupo lógico de objetivos registrados, donde cada objetivo es cualquier objeto con una dirección IP en su VDC, como un VM o otro Load Balancer. Puede reutilizar el mismo grupo de destino en varias reglas de reenvío.

1.1 Provisionar el Load Balancer y el grupo de destino

Comience con el Load Balancer y un grupo de destino. Cada objetivo se registra con una dirección IP, un puerto y un peso. El rango de peso del objetivo es 1 - 256, y lo utiliza para enviar proporcionalmente más tráfico a backends más grandes.

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 un ionoscloud_ipblock. Los algoritmos de equilibrio de carga admitidos son Round Robin, Menos Conexiones, Aleatorio y Origen IP, con Round Robin como predeterminado.

1.2 Reglas de reenvío y oyentes

Las reglas de reenvío definen cómo se distribuye el tráfico del cliente a los objetivos, y se puede crear más de una regla para el mismo Load Balancer. Una regla de reenvío enlaza un oyente IP y puerto con una regla HTTP que reenvía solicitudes coincidentes a un grupo de objetivos.

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. Más allá del enrutamiento basado en ruta simple, los tipos de enrutamiento incluyen enrutamiento basado en nombre de host, cadena de consulta, encabezado, método, cookie, origen IP, redirección de URL y respuestas fijas estáticas. Un ALB en su contrato puede tener desde 1 hasta 10 oyentes, y puede aprovisionar hasta 5 ALB por contrato.

1.3 TLS, WebSocket y gRPC

El ALB admite la descarga de TLS, por lo que termina HTTPS y envía HTTP simple a sus servidores back-end, eliminando el manejo de certificados de sus servidores de aplicaciones. Se admite SNI, lo que permite que un solo oyente sirva varios certificados por nombre de host. WebSocket y gRPC están ambos soportados, por lo que el mismo ALB es el front-end de un REST API y un punto de conexión de transmisión sin un proxy separado. La llamada cruda API para crear un ALB compatible con WebSocket tiene como objetivo 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. Red Load Balancer como código

Cuando necesita rendimiento bruto de L4 y no necesita enrutamiento de capa de aplicación, el recurso ionoscloud_networkloadbalancer proporciona un Load Balancer de capa 4. El NLB opera en la capa 4 de OSI y distribuye el tráfico TCP entre objetivos sin inspeccionar la carga.

El NLB tiene una sola interfaz de escucha que puede admitir múltiples IPs con diferentes reglas de reenvío. Un NLB público está expuesto a y acepta conexiones de clientes directamente desde Internet, sirviendo como un dispositivo de borde para el tráfico norte-sur. Sus algoritmos de equilibrio de carga son los mismos que los del ALB: Round Robin, Menos Conexiones, Aleatorio y Origen 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 NLB es solo TCP; UDP no es compatible, y las comprobaciones de salud HTTP no son compatibles, por lo que la comprobación de salud se basa en TCP. La adhesión de sesión en el NLB utiliza la afinidad de origen IP: una sesión de cliente permanece en el mismo objetivo mientras sus sesiones TCP siguen activas. El peso de objetivo predeterminado es 1 con un máximo de 256, y el valor predeterminado de la comprobación de salud es 3 reintentos. Puede aprovisionar hasta 5 NLB por contrato.

2.2 Elección de ALB versus NLB

La decisión está impulsada por qué capa necesita inspeccionar su enrutamiento. La siguiente tabla resume las dos opciones para decisiones de tiempo de código:

Elija el ALB cuando enruté por ruta de URL, host o encabezado, o cuando desee que el Load Balancer termine TLS. La TaskBoard API utiliza un ALB para que /api/tasks y /api/health puedan ser enrutados y TLS terminado en el borde. Elija el NLB para servicios TCP no HTTP, donde desee una distribución L4 de bajo sobrecarga y la aplicación maneje sus propias preocupaciones de protocolo.

3. Network Security Groups como código

Un grupo de seguridad de red es un Firewall con estado que se adjunta a sus máquinas virtuales y tarjetas de interfaz de red. La regla específica de IONOS que rige todo en esta sección: los GSN se unen al nivel de servidor-tarjeta de interfaz de red. No se aplican al ALB administrado o NLB, y los nodos de grupo de Managed Kubernetes Node se excluyen de los GSN. Usted protege los backends con equilibrio de carga escribiendo reglas en las tarjetas de interfaz de red de backend, no en el Load Balancer.

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

3.1 Adjuntar GSN y escribir reglas

La granularidad de adjunto es por VM, que cubre todas las tarjetas de interfaz de red de ese VM, o por tarjeta de interfaz de red para un control granular. Cuando un VM es miembro de un GSN, todas las tarjetas de interfaz de red del VM heredan implícitamente las reglas de Firewall. Cada tarjeta de interfaz de red puede llevar hasta 10 GSN, un VDC puede contener hasta 200 GSN, y cada GSN 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
}

Debido a que el Firewall es con estado, usted escribe solo la regla de entrada para un servicio TCP de entrada; el tráfico de retorno se permite automáticamente sin una regla de salida coincidente.

3.2 El API crudo y las propiedades de la regla

Bajo los recursos de Terraform, un GSN es la entidad security-group API y cada regla es una entidad firewall-rule. Solo los administradores de contrato, propietarios y usuarios con permisos para el VDC pueden crear y administrar GSN a través del API. La solicitud POST para agregar una regla tiene como objetivo el 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 GSN predeterminado contiene 4 reglas predefinidas: permitir todo IPv4 de salida, permitir todo IPv6 de salida, permitir IPv4 de entrada solo desde 10.0.0.0/24 y permitir IPv6 de entrada solo desde el /56 CIDR asignado del centro de datos. El efecto neto es que todo el tráfico de salida está permitido mientras que el tráfico de entrada está bloqueado excepto para los rangos explícitamente permitidos.

4. Seguridad de la capa con equilibrio de carga

La consecuencia arquitectónica fundamental de que los NSG se vinculen a las NIC es que el ALB no es un límite de seguridad que usted pueda configurar con reglas de Firewall. El tráfico que el ALB reenvía a su backend llega a la NIC de backend, y es allí donde se produce el filtrado. Por lo tanto, usted escribe sus reglas de NSG para permitir solo el tráfico de Load Balancer.

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

4.1 Reglas de aislamiento de capas

Las reglas de aislamiento de capas son fundamentales para garantizar la seguridad de su infraestructura en la nube. Al configurar reglas de NSG para permitir solo el tráfico necesario, usted puede reducir el riesgo de ataques y proteger sus datos. Recuerde que la seguridad es un proceso continuo, y es importante revisar y actualizar sus reglas de seguridad regularmente para asegurarse de que siguen siendo efectivas. En la siguiente sección, se discutirán las mejores prácticas para implementar reglas de seguridad en su infraestructura en la nube, incluyendo el uso de LAN y la configuración de reglas de tráfico para LAN, y finalmente, se analizarán los beneficios de utilizar LAN en su entorno de producción, junto con LAN.

# 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 sin reglas propias más allá de la que acaba de escribir, no recibe las reglas predeterminadas predefinidas de la plataforma (estas solo se aplican al propio NSG predeterminado del VDC); esta pila le da conectividad de entrada PostgreSQL desde la subred de la aplicación solo, y debe agregar una regla de salida explícita en db_tier si el servidor de base de datos necesita alguna conectividad de salida (por ejemplo DNS, NTP o actualizaciones). No hay regla que mencione el LAN público, por lo que la base de datos es inaccesible desde internet por construcción.

4.2 Adjuntar el NSG a las NIC de backend

El NSG solo tiene efecto una vez que se adjunta a las NIC que debe proteger. Adjunte el NSG de app-tier a las NIC del servidor API y el NSG de db-tier a las NIC del servidor de base de datos. Dado que la membresía se hereda de todas las NIC de un miembro VM, puede adjuntar a nivel de VM cuando un servidor tiene una sola NIC relevante.

resource "ionoscloud_nsg_share" "api_nics" {
  for_each      = toset([ionoscloud_server.api_1.id, ionoscloud_server.api_2.id])
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = each.value
  nsg_id        = ionoscloud_nsg.app_tier.id
}

El resultado es una postura de defensa en profundidad escrita entirely en Terraform: el ALB distribuye y termina TLS, mientras que los NSGs en las NIC de backend hacen cumplir que solo el tráfico pretendido llega a cada nivel.

API Tarjeta de referencia rápida

Puntos de conexión clave de API 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: Proporcionar un ALB para la TaskBoard API con Terraform, agregar reglas de NSG a los niveles de aplicación y base de datos, y verificar la routificación y la isolación.

Requisitos previos:

• Cuenta de IONOS Cloud con token 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, LAN, servidores)

Paso 1: Reservar un IP público para el ALB

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

No hay texto para traducir. Por favor, proporcione el texto técnico que desea que traduzca.

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

Paso 2: Agregar el Load Balancer y el grupo objetivo

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

No hay texto para traducir. Por favor, proporcione el texto técnico que desea traducir.

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

No hay texto que traducir. Por favor, proporcione el texto técnico que desea que traduzca.

ionoscloud_application_loadbalancer_forwardingrule.api_http: Creation complete

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

terraform apply \
  -target=ionoscloud_nsg.app_tier \
  -target=ionoscloud_nsg_firewallrule.allow_api_from_app_lan \
  -target=ionoscloud_nsg_share.api_nics

No hay texto para traducir. Por favor, proporcione el texto que desea traducir.

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

Paso 5: Crear el NSG de nivel de base de datos con la regla de aislamiento

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

No hay texto para traducir. Por favor, proporcione el texto técnico que desea que traduzca.

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

Paso 6: Verificar las rutas del ALB al API

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

No hay texto que traducir. Por favor, proporcione el texto técnico que desea que traduzca.

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

No hay texto para traducir. Por favor, proporcione el texto técnico que necesita ser traducido al español.

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 del público reservado IP
• [ ] Las NIC de la aplicación aceptan TCP 8080 solo desde la subred de la aplicación
• [ ] PostgreSQL en el nivel de base de datos es inaccesible 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 los desarrolladores que deben evitarse con el equilibrio de carga y la seguridad en IONOS Cloud:

1. Intentar adjuntar un NSG al Load Balancer

   • Problema: Usted escribe reglas Firewall esperando que filtren el tráfico en el ALB, pero no tienen efecto.
   • Por qué sucede: Los NSGs se unen solo al nivel de la NIC del servidor. No se aplican al Managed ALB o NLB, y los nodos del Node Pool de Managed Kubernetes están excluidos por completo.
   • Solución: Escriba las reglas en las NICs de backend. Permita solo el tráfico adelantado por el equilibrador de carga y aísle cada nivel en sus propias NICs.

2. Escribir reglas de salida para servicios de entrada

   • Problema: Usted agrega una regla de entrada para TCP 8080 y una regla de salida coincidente para la respuesta, entonces el tráfico se comporta de manera inconsistente o usted abre demasiado el NSG.
   • Por qué sucede: El NSG de IONOS es un Firewall con estado, por lo que el tráfico de retorno para una conexión de entrada permitida se permite automáticamente.
   • Solución: Escriba solo la regla de entrada para un servicio de entrada. Reserve las reglas de salida para las conexiones que su servidor inicia.

3. Olvidar que el ALB necesita una dirección IP pública reservada

   • Problema: terraform apply falla al crear un ALB público porque no se proporciona una dirección IP pública utilizable.
   • Por qué sucede: Un ALB público requiere una dirección IP pública reservada, suministrada a través del argumento ips.
   • Solución: Proporcione primero un ionoscloud_ipblock y haga referencia a ionoscloud_ipblock.alb_ip.ips[0] tanto en el Load Balancer como en el oyente de la regla de reenvío.

Resumen

Ahora puede colocar un Load Balancer gestionado delante de un nivel y asegurar ese nivel por completo en código. El ALB maneja el enrutamiento de la capa 7, la descarga de TLS y protocolos como WebSocket y gRPC, mientras que el NLB le ofrece una distribución de TCP de capa 4 con un mínimo de sobrecarga. Los Network Security Groups aplican un filtrado de denegación de todo el tráfico por NIC, y usted asegura los backends con equilibrio de carga escribiendo reglas en las NICs de backend porque el Load Balancer en sí no es un objetivo de NSG.

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

Puntos clave:

• El ALB se construye a partir de tres recursos: ionoscloud_application_loadbalancer, ionoscloud_target_group, y ionoscloud_forwardingrule
• Elija el ALB para el enrutamiento de aplicaciones HTTP y HTTPS, y la descarga de TLS; elija el NLB para la distribución de TCP de capa 4
• Los NSGs se unen al nivel de la NIC del servidor, nunca al ALB, NLB, o nodos Managed Kubernetes
• Los NSGs se configuran por defecto para denegar todo el tráfico y son estado, así que solo escriba reglas de entrada para servicios de entrada
• Asegure un nivel con equilibrio de carga filtrando en las NICs de backend e isolando cada nivel con su propio NSG

Terminología importante:

• Grupo de destino: Un grupo lógico de objetivos registrados (IP, puerto, peso) al que un ALB distribuye tráfico; reutilizable en reglas de reenvío.
• Regla de reenvío: Una regla que une un listener IP y puerto con objetivos, definiendo cómo el Load Balancer distribuye el tráfico de cliente.
• Listener: La interfaz orientada al cliente de un Load Balancer que acepta conexiones en un IP expuesto y un puerto configurado.
• Grupo de seguridad de red (NSG): Un Firewall estado, denegación de todo el tráfico, unido por NIC o por VM, que puede contener hasta 100 reglas.
• Descarga de TLS: Terminar HTTPS en el ALB y reenviar HTTP plano a los backends, eliminando el manejo de certificados de los servidores de aplicación.

Próximos pasos

Continúe aprendiendo: Unidad 2.4: Provisionamiento de almacenamiento como código

Temas relacionados:

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