Unité 2.3 : Équilibrage de charge et sécurité en tant que code

Introduction

La pile réseau de votre TaskBoard, issue de l'unité 2.2, comporte trois niveaux interconnectés : un LAN public, un LAN applicatif et un LAN de base de données. Les serveurs API sont accessibles sur le LAN applicatif, mais rien ne les préserve encore, et rien ne filtre le trafic qui atteint leurs cartes réseau. Dans cette unité, vous configurez le point d'accès.

Vous placez un Managed Application Load Balancer devant l'API, afin de distribuer les requêtes HTTP entre les serveurs applicatifs au moyen d'un routage basé sur les chemins d'accès. Vous découvrirez dans quels cas un Network Load Balancer est l'outil approprié, et vous verrouillez chaque niveau à l'aide de règles de Network Security Group. La leçon spécifique à IONOS CLOUD qui revêt une importance particulière ici concerne le point d'application de la sécurité : les NSGs s'appliquent au niveau de la carte réseau du serveur, jamais au niveau du load balancer et jamais au niveau des nœuds Managed Kubernetes. Une erreur à ce niveau vous fera perdre des heures à vous demander pourquoi vos règles de pare-feu n'ont aucun effet sur le trafic arrivant via l'ALB. Tout le contenu de cette unité est du code : des ressources Terraform et les appels bruts de l'API Cloud qui les sous-tendent.

1. Application Load Balancer en tant que code

La ressource ionoscloud_application_loadbalancer provisionne un Load Balancer de couche 7 qui met fin aux connexions HTTP et HTTPS et effectue le routage en fonction d'attributs au niveau de l'application. L'ALB est situé entre un LAN d'écoute, où les clients y accèdent, et un LAN cible, où vos backends sont hébergés. Pour l'API TaskBoard, le LAN d'écoute est le LAN public et le LAN cible est le LAN de l'application.

Un ALB est constitué de trois types de ressources : le Load Balancer lui-même, un ou plusieurs groupes de cibles qui enregistrent les cibles backend, et des règles de transfert qui associent un écouteur à ces cibles. Un groupe de cibles est un regroupement logique de cibles enregistrées, où chaque cible est tout objet disposant d'une adresse IP dans votre VDC, tel qu'une VM ou un autre Load Balancer. Vous pouvez réutiliser le même groupe de cibles dans plusieurs règles de transfert.

1.1 Provisionnement du Load Balancer et du groupe de cibles

Commencez par le Load Balancer et un groupe de cibles. Chaque cible est enregistrée avec une IP, un port et un poids. La plage des poids des cibles est 1 - 256, et vous l'utilisez pour envoyer proportionnellement plus de trafic vers les backends plus volumineux.

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
  }
}

Une ALB publique nécessite une IP publique réservée, c'est pourquoi l'argument ips fait référence à un ionoscloud_ipblock. Les algorithmes d'équilibrage de charge pris en charge sont Round Robin, Least Connections, Random et Source IP, avec Round Robin par défaut.

1.2 Règles de transfert et écouteurs

Les règles de transfert définissent la manière dont le trafic des clients est distribué vers les cibles, et plus d'une règle peut être créée pour le même équilibreur de charge. Une règle de transfert associe l'IP et le port d'un écouteur à une règle HTTP qui transfère les requêtes correspondantes vers un groupe de cibles.

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
  }
}

L'ALB prend en charge les protocoles HTTP et HTTPS sur HTTP1 et HTTP2. Au-delà de la simple redirection basée sur le chemin, les types de routage incluent le routage basé sur le nom d'hôte, la chaîne de requête, les en-têtes, la méthode, les cookies, l'adresse IP source, la redirection d'URL et les réponses statiques fixes. Un ALB dans votre contrat peut comporter de 1 à 10 écouteurs, et vous pouvez provisionner jusqu'à 5 ALB par contrat.

1.3 TLS, WebSocket et gRPC

L'ALB prend en charge la décharge TLS, ce qui signifie qu'il termine les connexions HTTPS et transmet le HTTP en clair vers vos backends, en supprimant la gestion des certificats de vos serveurs d'application. SNI est pris en charge, ce qui permet à un seul écouteur de servir plusieurs certificats par nom d'hôte. WebSocket et gRPC sont tous deux pris en charge, de sorte que le même ALB peut servir d'interface à une API REST et à un point de terminaison de streaming sans proxy séparé. L'appel API brut pour créer un ALB compatible WebSocket cible la collection 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 en tant que code

Lorsque vous avez besoin d'un débit L4 brut et que le routage au niveau de la couche applicative n'est pas nécessaire, la ressource ionoscloud_networkloadbalancer provisionne un équilibreur de charge de couche 4. Le NLB fonctionne à la couche 4 du modèle OSI et distribue le trafic TCP entre les cibles sans inspecter la charge utile.

Le NLB dispose d'une interface d'écoute unique qui peut prendre en charge plusieurs IP avec des règles de transfert différentes. Un NLB public est exposé à Internet et accepte les connexions des clients directement depuis Internet, servant de dispositif de bord pour le trafic nord-sud. Ses algorithmes d'équilibrage de charge sont le même ensemble que ceux de l'ALB : Round Robin, Least Connections, Random et Source IP.

2.1 Provisionnement d'un NLB avec des règles de transfert

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
  }
}

L'ensemble de protocoles pris en charge par NLB est limité à TCP ; UDP n'est pas pris en charge, et les vérifications d'intégrité HTTP ne sont pas non plus supportées, de sorte que les vérifications d'intégrité sont basées sur TCP. La persistance de session sur NLB utilise l'affinité par adresse IP source : une session client reste sur la même cible tant que ses sessions TCP restent actives. Le poids par défaut des cibles est de 1, avec un maximum de 256, et le nombre de tentatives par défaut pour les vérifications d'intégrité est de 3. Vous pouvez provisionner jusqu'à 5 instances NLB par contrat.

2.2 Choisir entre ALB et NLB

La décision est déterminée par la couche que vos besoins de routage doivent inspecter. Le tableau suivant résume les deux options pour les décisions au moment de l'écriture du code :

Choisissez ALB lorsque vous effectuez le routage par chemin d'URL, hôte ou en-tête, ou lorsque vous souhaitez que l'équilibreur de charge mette fin aux connexions TLS. L'API TaskBoard utilise un ALB afin que /api/tasks et /api/health puissent être routés et que le TLS soit terminé au niveau de la périphérie. Choisissez NLB pour les services TCP non HTTP, lorsque vous souhaitez une distribution L4 à faible surcharge et que l'application gère elle-même les aspects liés au protocole.

3. Network Security Groups en tant que code

Un Network Security Group est un pare-feu à état que vous attachez à vos VM et à vos NIC. La règle spécifique à IONOS CLOUD qui régit tout dans cette section : les NSG sont liés au niveau serveur-NIC. Ils ne s'appliquent pas au Managed ALB ou NLB, et les nœuds des pools de nœuds de Managed Kubernetes sont exclus des NSG. Vous sécurisez les backends équilibrés en charge en rédigeant des règles sur les NIC des backends, et non sur l'équilibreur de charge.

L'action par défaut d'un NSG est de tout refuser, de sorte que le trafic est bloqué à moins qu'une règle explicite ne l'autorise. Les règles ont une direction, soit INGRESS soit EGRESS, et les deux directions sont prises en charge. Les protocoles pris en charge sont TCP, UDP, ICMP, ICMPv6, GRE, VRRP, ESP, AH et ANY.

3.1 Attacher des NSG et rédiger des règles

La granularité de l'attachement est par VM, ce qui couvre toutes les NIC de cette VM, ou par NIC pour un contrôle granulaire. Lorsqu'une VM est membre d'un NSG, toutes les NIC de la VM héritent implicitement des règles du pare-feu. Chaque NIC peut porter jusqu'à 10 NSG, un VDC peut contenir jusqu'à 200 NSG, et chaque NSG peut contenir jusqu'à 100 règles.

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
}

Étant donné que le pare-feu est à état, vous n'écrivez que la règle d'entrée pour un service TCP entrant ; le trafic de retour est autorisé automatiquement sans règle de sortie correspondante.

3.2 L'API brute et les propriétés des règles

Sous les ressources Terraform, un NSG est l'entité API security-group et chaque règle est une entité firewall-rule. Seuls les administrateurs de contrat, les propriétaires et les utilisateurs disposant des autorisations sur le VDC concerné peuvent créer et gérer des NSG via l'API. La requête POST destinée à ajouter une règle cible le groupe de sécurité sur un centre de données :

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}}'

Les noms des propriétés de règle sont name, protocol, sourceMac, ipVersion, sourceIp, targetIp, portRangeStart, portRangeEnd, icmpCode, icmpType et type. Un NSG par défaut contient 4 règles prédéfinies : autoriser toutes les sorties IPv4, autoriser toutes les sorties IPv6, autoriser les entrées IPv4 uniquement depuis 10.0.0.0/24, et autoriser les entrées IPv6 uniquement depuis le CIDR /56 alloué au centre de données. L'effet net est que tout le trafic sortant est autorisé, tandis que le trafic entrant est bloqué, à l'exception des plages explicitement autorisées.

4. Sécurisation de la couche équilibrée de charge

La conséquence architecturale fondamentale du fait que les NSG soient liés aux NIC est que l'ALB ne constitue pas une frontière de sécurité que vous pouvez configurer avec des règles de pare-feu. Le trafic que l'ALB transfère vers votre backend arrive sur la NIC du backend, et c'est sur cette NIC que le filtrage a lieu. Vous devez donc rédiger vos règles NSG afin de n'autoriser que le trafic de l'équilibreur de charge.

Pour la couche d'application de l'application TaskBoard, l'ALB réside sur le LAN (public) de l'écouteur et transfère le trafic vers le LAN de l'application. Les NIC des serveurs d'application doivent accepter le TCP sur le port de l'API uniquement depuis le sous-réseau du LAN de l'application, et rejeter tout le reste. Les NIC de la couche de base de données doivent accepter le trafic PostgreSQL uniquement depuis le LAN de l'application, et jamais depuis le LAN public.

4.1 Règles d'isolation des couches

# 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
}

Étant donné que db_tier est un NSG personnalisé ne comportant aucune règle propre au-delà de celle que vous venez de définir, il ne reçoit pas les règles par défaut prédéfinies de la plateforme (celles-ci ne s'appliquent qu'au NSG par défaut propre au VDC). Cette pile vous offre uniquement un accès entrant PostgreSQL depuis le sous-réseau d'application, et vous devez ajouter une règle de sortie explicite sur db_tier si le serveur de base de données a besoin d'une connectivité sortante (par exemple pour DNS, NTP ou les correctifs). Aucune règle ne mentionne le LAN public, de sorte que la base de données est inatteignable depuis Internet par conception.

4.2 Association du NSG aux interfaces réseau des serveurs backend

Le NSG ne prend effet qu'une fois associé aux interfaces réseau qu'il doit protéger. Associez le NSG de la couche d'application aux interfaces réseau des serveurs API et le NSG de la couche de base de données aux interfaces réseau des serveurs de base de données. Étant donné que l'appartenance est héritée par toutes les interfaces réseau d'une VM membre, vous pouvez effectuer l'association au niveau de la VM lorsqu'un serveur ne dispose que d'une seule interface réseau pertinente.

# 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]
}

Le résultat est une posture de défense en profondeur entièrement rédigée dans Terraform : l'ALB distribue et met fin aux connexions TLS, tandis que les NSG sur les NIC du backend garantissent que seul le trafic prévu atteint chaque niveau.

Fiche de référence rapide de l'API

Points de terminaison API clés pour l'équilibrage de charge et la sécurité :

URL de base : https://api.ionos.com/cloudapi/v6 Authentification : Authorization: Bearer <token>

Atelier de code

Objectif : Provisionner un ALB pour l'API TaskBoard à l'aide de Terraform, ajouter des règles NSG aux couches applicative et de base de données, et vérifier le routage et l'isolation.

Prérequis :

• Compte IONOS CLOUD avec jeton API (IONOS_TOKEN exporté)
• Terraform avec le fournisseur ionoscloud configuré
• La pile réseau TaskBoard de l'Unité 2.2 déjà appliquée (datacenter, LANs, serveurs)

Étape 1 : Réserver une IP publique pour l'ALB

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

Sortie attendue :

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

Étape 2 : Ajouter l'équilibreur de charge et le groupe de cibles

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

Sortie attendue :

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

Étape 3 : Ajouter la règle de transfert

terraform apply -target=ionoscloud_application_loadbalancer_forwardingrule.api_http

Sortie attendue :

ionoscloud_application_loadbalancer_forwardingrule.api_http: Creation complete

Étape 4 : Créer et associer le NSG de la couche d'application

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

Sortie attendue :

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

Étape 5 : Créer le NSG de la couche BD avec la règle d'isolation

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

Sortie attendue :

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

Étape 6 : Vérifier que l'ALB achemine vers l'API

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

Sortie attendue :

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

Étape 7 : Vérifier l'isolation de la base de données depuis le côté public

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

Sortie attendue :

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

Liste de contrôle de validation :

• [ ] ALB renvoie 200 sur /api/health via l'adresse IP publique réservée
• [ ] Les NIC de l'application acceptent le TCP 8080 uniquement depuis le sous-réseau de l'application
• [ ] PostgreSQL sur la couche base de données est inaccessible depuis l'extérieur du sous-réseau de l'application

Nettoyage :

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

Erreurs courantes

Erreurs de développement à éviter lors de l'équilibrage de charge et de la sécurité sur IONOS CLOUD :

1. Tentative d'attacher un NSG à l'équilibreur de charge

   • Problème : Vous rédigez des règles de pare-feu en vous attendant à ce qu'elles filtrent le trafic au niveau de l'ALB, mais elles n'ont aucun effet.
   • Pourquoi cela se produit : Les NSG sont liés uniquement au niveau de l'interface réseau du serveur. Ils ne s'appliquent ni à l'ALB managé ni au NLB, et les nœuds des pools de nœuds de Managed Kubernetes sont entièrement exclus.
   • Correction : Rédigez les règles sur les interfaces réseau des serveurs en aval. Autorisez uniquement le trafic transmis par l'équilibreur de charge en entrée, et isolez chaque niveau au niveau de ses propres interfaces réseau.

2. Rédaction de règles de sortie pour des services entrants

   • Problème : Vous ajoutez une règle d'entrée pour le TCP 8080 et une règle de sortie correspondante pour la réponse, puis le trafic se comporte de manière incohérente ou vous ouvrez excessivement le NSG.
   • Pourquoi cela se produit : Le NSG d'IONOS CLOUD est un pare-feu avec état, de sorte que le trafic de retour pour une connexion entrante autorisée est permis automatiquement.
   • Correction : Rédigez uniquement la règle d'entrée pour un service entrant. Réservez les règles de sortie pour les connexions initiées par votre serveur.

3. Oubli que l'ALB nécessite une IP publique réservée

   • Problème : terraform apply échoue lors de la création d'un ALB public car aucune IP publique utilisable n'est fournie.
   • Pourquoi cela se produit : Un ALB public nécessite une IP publique réservée, fournie via l'argument ips.
   • Correction : Provisionnez d'abord un ionoscloud_ipblock et référencez ionoscloud_ipblock.alb_ip.ips[0] à la fois dans l'équilibreur de charge et dans l'écouteur de la règle de transfert.

Résumé

Vous pouvez désormais placer un équilibreur de charge managé devant une couche et sécuriser entièrement cette couche par le biais du code. L'ALB gère le routage de niveau 7, la déportation TLS et des protocoles tels que WebSocket et gRPC, tandis que le NLB vous offre une distribution TCP de niveau 4 avec un surcharge minimale. Les Network Security Groups appliquent un filtrage par interface réseau, avec état et par défaut en mode refus de tout, et vous sécurisez les serveurs en aval équilibrés en charge en écrivant des règles sur les interfaces réseau des serveurs, car l'équilibreur de charge lui-même n'est pas une cible NSG.

Pour TaskBoard, l'API est désormais placée derrière un ALB sur le LAN public, les interfaces réseau de l'application n'acceptent que le trafic API transféré depuis le sous-réseau de l'application, et la base de données n'est accessible que depuis la couche applicative. L'unité suivante provisionne la couche de stockage dont ces serveurs dépendent.

Points clés :

• L'ALB est constitué de trois ressources : ionoscloud_application_loadbalancer, ionoscloud_target_group et ionoscloud_application_loadbalancer_forwardingrule
• Choisissez l'ALB pour le routage applicatif HTTP et HTTPS et la déportation TLS ; choisissez le NLB pour la distribution TCP de niveau 4
• Les NSG sont liés uniquement au niveau de l'interface réseau du serveur, jamais à l'ALB, au NLB ou aux nœuds Managed Kubernetes
• Les NSG sont par défaut en mode refus de tout et avec état, il faut donc n'écrire que des règles d'entrée pour les services entrants
• Sécurisez une couche équilibrée en charge en filtrant sur les interfaces réseau des serveurs en aval et en isolant chaque couche avec son propre NSG

Terminologie importante :

• Groupe de cibles : Un regroupement logique de cibles enregistrées (IP, port, poids) vers lesquelles un ALB distribue le trafic ; réutilisable entre les règles de transfert.
• Règle de transfert : Une règle liant l'IP et le port d'un écouteur à des cibles, définissant comment l'équilibreur de charge distribue le trafic des clients.
• Écouteur : L'interface côté client d'un équilibreur de charge qui accepte les connexions sur une IP exposée et un port configuré.
• Network Security Group (NSG) : Un pare-feu avec état et par défaut en mode refus de tout, attaché par VM ou par interface réseau, pouvant contenir jusqu'à 100 règles.
• Déportation TLS : La terminaison HTTPS sur l'ALB et le transfert de HTTP en clair vers les serveurs en aval, supprimant la gestion des certificats des serveurs applicatifs.

Prochaines étapes

Continuer l'apprentissage : Unité 2.4 : Provisioning du stockage en tant que code

Sujets connexes :

• Unité 2.2 : Réseau et connectivité en tant que code
• Unité 5.2 : Automatisation de la sécurité