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

Introduction

Votre pile réseau TaskBoard de l'unité 2.2 comporte trois niveaux reliés entre eux : un LAN public, un LAN d'application et un LAN de base de données. Les serveurs API sont accessibles sur le LAN d'application, mais rien ne les précède encore, et rien ne filtre le trafic qui atteint leurs cartes réseau. Dans cette unité, vous configurez le périmètre.

Vous placerez un Managed Application Load Balancer devant les serveurs API, en distribuant les requêtes HTTP à travers les serveurs d'application avec un routage basé sur les chemins. Vous verrez quand un Load Balancer de réseau est l'outil approprié, et vous verrez comment verrouiller chaque niveau avec des règles de groupe de sécurité réseau. La leçon importante spécifique à IONOS ici est où la sécurité est réellement liée : les groupes de sécurité réseau s'appliquent au niveau du serveur-carte réseau, jamais au Load Balancer et jamais aux nœuds Managed Kubernetes. Si vous vous trompez, vous passerez des heures à vous demander pourquoi vos règles de pare-feu n'ont aucun effet sur le trafic qui arrive via l'ALB. Tout dans cette unité est du code : les ressources Terraform et les appels Cloud API bruts sous-jacents.

1. Application Load Balancer en tant que code

La ressource ionoscloud_application_loadbalancer provisionne un Load Balancer de couche 7 qui met fin à HTTP et HTTPS et achemine en fonction d'attributs au niveau de l'application. L'ALB est situé entre un écouteur LAN, où les clients y accèdent, et une cible LAN, où vivent vos serveurs principaux. Pour le TaskBoard API, l'écouteur LAN est l'adresse LAN publique et la cible LAN est l'application LAN.

Un ALB est construit à partir de trois types de ressources : le Load Balancer lui-même, un ou plusieurs groupes cibles qui enregistrent les cibles principales, et des règles de transfert qui cartographient un écouteur à ces cibles. Un groupe cible est un regroupement logique de cibles enregistrées, où chaque cible est n'importe quel objet avec une adresse IP dans votre centre de données virtuel, comme un VM ou un autre Load Balancer. Vous pouvez réutiliser le même groupe cible dans plusieurs règles de transfert.

1.1 Provisionnement du Load Balancer et du groupe cible

Commencez par le Load Balancer et un groupe cible. Chaque cible est enregistrée avec une adresse IP, un port et un poids. La plage de poids de la cible est 1 - 256, et vous l'utilisez pour envoyer proportionnellement plus de trafic aux serveurs principaux plus importants.

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 public nécessite un IP public réservé, 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 comme valeur par défaut.

1.2 Règles de transfert et écouteurs

Les règles de transfert définissent la façon dont le trafic client est distribué aux cibles, et plus d'une règle peut être créée pour le même Load Balancer. Une règle de transfert lie un écouteur IP et un port à une règle HTTP qui transfère les requêtes correspondantes à un groupe cible.

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

Le ALB prend en charge les protocoles HTTP et HTTPS sur HTTP1 et HTTP2. Au-delà du routage basé 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, les méthodes, les cookies, la source IP, la redirection d'URL et les réponses fixes statiques. Un ALB sur votre contrat peut contenir de 1 à 10 écouteurs, et vous pouvez provisionner jusqu'à 5 ALBs par contrat.

1.3 TLS, WebSocket, et gRPC

Le ALB prend en charge le déchargement TLS, il termine donc HTTPS et transmet le HTTP plain à vos serveurs principaux, supprimant ainsi la gestion des certificats de vos serveurs d'applications. Le 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 fait office de frontale pour un REST API et un point de terminaison de diffusion sans proxy séparé. L'appel brut API 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. Réseau Load Balancer en tant que code

Lorsque vous avez besoin d'un débit brut L4 et que vous n'avez pas besoin de routage au niveau de l'application, la ressource ionoscloud_networkloadbalancer met en place un Load Balancer de niveau 4. Le NLB fonctionne au niveau 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 adresses IP avec des règles de transfert différentes. Un NLB public est exposé à et accepte les connexions clientes directement depuis Internet, servant de périphérique de bordure pour le trafic nord-sud. Ses algorithmes d'équilibrage de charge sont les mêmes que ceux de l'ALB : Round Robin, Least Connections, Random et Source IP.

2.1 Mise en place 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 NLB est limité à TCP uniquement ; UDP n'est pas pris en charge, et les vérifications d'intégrité HTTP ne sont pas prises en charge, donc la vérification d'intégrité est basée sur TCP. La persistance de session sur le NLB utilise l'affinité Source IP : une session cliente reste sur la même cible tant que ses sessions TCP restent actives. Le poids cible par défaut est 1 avec un maximum de 256, et la vérification d'intégrité par défaut est de 3 réessais. Vous pouvez mettre en place jusqu'à 5 NLB par contrat.

2.2 Choix entre ALB et NLB

La décision est dictée par le niveau de routage que vous devez inspecter. Le tableau suivant résume les deux options pour les décisions à l'exécution du code :

Choisissez l'ALB lorsque vous routez par chemin d'URL, hôte ou en-tête, ou lorsque vous souhaitez que le Load Balancer mette fin à TLS. La TaskBoard API utilise un ALB afin que /api/tasks et /api/health puissent être routés et TLS terminé à la bordure. Choisissez le NLB pour les services TCP non HTTP, où vous souhaitez une distribution L4 à faible surcharge et que l'application gère ses propres préoccupations de protocole.

3. Network Security Groups as Code

Un groupe de sécurité réseau est un pare-feu à état que vous attachez à vos machines virtuelles et à vos cartes réseau. La règle spécifique à IONOS qui régit tout dans cette section : les groupes de sécurité réseau se lient au niveau du serveur-carte réseau. Ils ne s'appliquent pas au Managed ALB ou NLB, et les nœuds de pool Managed Kubernetes Node sont exclus des groupes de sécurité réseau. Vous sécurisez les backends équilibrés en charge en écrivant des règles sur les cartes réseau des backends, et non sur le Load Balancer.

L'action par défaut d'un groupe de sécurité réseau est de refuser tout, donc le trafic est bloqué à moins qu'une règle explicite ne l'autorise. Les règles portent une direction, soit INGRESS ou 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 groupes de sécurité réseau et écrire des règles

La granularité d'attachement est par VM, ce qui couvre toutes les cartes réseau de ce VM, ou par carte réseau pour un contrôle plus précis. Lorsqu'un VM est membre d'un groupe de sécurité réseau, toutes les cartes réseau de ce VM héritent implicitement des règles de pare-feu. Chaque carte réseau peut porter jusqu'à 10 groupes de sécurité réseau, un centre de données virtuel peut contenir jusqu'à 200 groupes de sécurité réseau, et chaque groupe de sécurité réseau 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
}

Puisque 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 Le groupe de sécurité réseau brut et les propriétés de règle

Sous les ressources Terraform, un groupe de sécurité réseau est l'entité security-group API et chaque règle est une entité firewall-rule. Seuls les administrateurs de contrat, les propriétaires et les utilisateurs ayant des autorisations sur le centre de données virtuel concerné peuvent créer et gérer des groupes de sécurité réseau via le API. La requête POST pour 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 de propriétés de règle sont name, protocol, sourceMac, ipVersion, sourceIp, targetIp, portRangeStart, portRangeEnd, icmpCode, icmpType, et type. Un groupe de sécurité réseau par défaut contient 4 règles prédéfinies : autoriser toutes les sorties IPv4, autoriser toutes les sorties IPv6, autoriser l'entrée IPv4 uniquement à partir de 10.0.0.0/24, et autoriser l'entrée IPv6 uniquement à partir de l'allocation /56 CIDR du centre de données. L'effet net est que tout le trafic sortant est autorisé tandis que l'entrée est bloquée, à l'exception des plages explicitement autorisées.

4. Sécurisation du niveau équilibré de charge

La conséquence architecturale fondamentale du lien entre les groupes de sécurité réseau (NSG) et les cartes réseau (NIC) est que l'équilibrage de charge application (ALB) n'est pas une limite de sécurité que vous pouvez configurer avec des règles de pare-feu. Le trafic que l'ALB transmet à votre backend arrive sur la carte réseau backend, et c'est là que se produit le filtrage. Vous devez donc écrire vos règles NSG pour n'autoriser que le trafic de Load Balancer.

Pour le niveau d'application TaskBoard, l'ALB se trouve sur l'écouteur (public) LAN et transmet dans l'application LAN. Les cartes réseau des serveurs d'application doivent accepter les connexions TCP sur le port API à partir du sous-réseau d'application LAN uniquement, et rejeter tout le reste. Les cartes réseau du niveau de base de données doivent accepter le trafic PostgreSQL uniquement à partir de l'application LAN, et jamais à partir de l'écouteur public LAN.

4.1 Règles d'isolement de niveau

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

Puisque db_tier est un NSG personnalisé sans règles autres que celle que vous venez d'écrire, il ne reçoit pas les règles par défaut prédéfinies de la plateforme (celles-ci ne s'appliquent qu'au Default NSG du VDC) ; cette pile vous donne une connectivité entrante PostgreSQL à partir du sous-réseau d'application uniquement, 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 DNS, NTP ou correction). Il n'y a pas de règle qui mentionne le LAN public, donc la base de données est inaccessible depuis internet par construction.

4.2 Attacher le NSG aux NICs de backend

Le NSG n'entre en vigueur qu'une fois qu'il est attaché aux NICs qu'il doit protéger. Attachez le NSG de l'app-tier au serveur API NICs et le NSG de db-tier aux NICs du serveur de base de données. Puisque l'appartenance est héritée par tous les NICs d'un membre VM, vous pouvez attacher au niveau VM lorsque le serveur a une seule NIC pertinente.

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
}

Le résultat est une posture de défense en profondeur écrite entièrement en Terraform : le ALB distribue et met fin à TLS, tandis que les NSGs sur les NIC de backend font respecter le fait que seul le trafic prévu atteint chaque niveau.

API Référence Quick Card

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

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

Laboratoire de code

Objectif : Mettre à disposition un ALB pour le TaskBoard API avec Terraform, ajouter des règles NSG aux niveaux application et base de données, et vérifier le routage et l'isolement.

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 (centre de données, LAN, serveurs)

Étape 1 : Réserver un IP public 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 le Load Balancer et le groupe cible

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 attacher le NSG de niveau application

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

Sortie attendue :

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

Étape 5 : Créer le NSG du niveau DB avec la règle d'isolement

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

Le texte à traduire est vide, veuillez fournir le texte technique à traduire.

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

Étape 6 : Vérifiez les routes ALB vers le API

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

Le texte à traduire est vide, veuillez fournir le texte à traduire.

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

Étape 7 : Vérifier l'isolement de la base de données du 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 validation :

• [ ] ALB retourne 200 sur /api/health via le public réservé IP
• [ ] Les cartes réseau de l'application acceptent TCP 8080 à partir du sous-réseau d'application uniquement
• [ ] PostgreSQL sur le niveau de la base de données est inaccessible depuis l'extérieur du sous-réseau d'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 avec l'équilibrage de charge et la sécurité sur IONOS Cloud :

1. Tenter d'attacher un NSG au Load Balancer

   • Problème : Vous écrivez des règles de pare-feu en vous attendant à ce qu'elles filtrent le trafic à l'ALB, mais elles n'ont aucun effet.
   • Pourquoi cela se produit : Les NSG sont liés uniquement au niveau de la carte réseau du serveur. Ils ne s'appliquent pas à l'ALB géré ou au NLB, et les nœuds du pool Managed Kubernetes Node sont exclus entièrement.
   • Correction : Écrivez les règles sur les cartes réseau de backend. Autorisez uniquement le trafic transféré par l'équilibreur de charge à entrer, et isolez chaque niveau à ses propres cartes réseau.

2. Écrire des règles de sortie pour des services entrants

   • Problème : Vous ajoutez une règle d'entrée pour 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 trop le NSG.
   • Pourquoi cela se produit : Le NSG IONOS est un pare-feu étatique, donc le trafic de retour pour une connexion entrante autorisée est permis automatiquement.
   • Correction : Écrivez uniquement la règle d'entrée pour un service entrant. Réservez les règles de sortie pour les connexions que votre serveur initie.

3. Oublier que l'ALB a besoin d'une adresse IP publique réservée

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

Résumé

Vous pouvez maintenant placer un Load Balancer géré devant un niveau et sécuriser entièrement ce niveau en code. L'ALB gère le routage de la couche 7, le déchargement de TLS et les protocoles comme WebSocket et gRPC, tandis que le NLB vous offre une distribution TCP de la couche 4 avec un minimum de surcharge. Les Network Security Groups imposent un filtrage d'interdiction totale, étatique et par NIC, et vous sécurisez les backends équilibrés de charge en écrivant des règles sur les NICs de backend, car le Load Balancer lui-même n'est pas une cible de NSG.

Pour TaskBoard, le API est maintenant situé derrière un ALB sur le LAN public, les NICs d'application n'acceptent que le trafic API transféré à partir du sous-réseau d'application, et la base de données n'est accessible qu'à partir du niveau d'application. La prochaine unité met en place le niveau de stockage dont dépendent ces serveurs.

Points clés :

• L'ALB est construit à partir de trois ressources : ionoscloud_application_loadbalancer, ionoscloud_target_group, et ionoscloud_forwardingrule
• Choisissez l'ALB pour le routage d'applications HTTP et HTTPS et le déchargement de TLS ; choisissez le NLB pour la distribution TCP de la couche 4
• Les NSG sont liés au niveau du serveur-NIC uniquement, et non à l'ALB, NLB, ou aux nœuds Managed Kubernetes
• Les NSG sont par défaut à interdiction totale et sont étatiques, donc écrivez uniquement des règles d'entrée pour les services entrants
• Sécurisez un niveau équilibré de charge en filtrant sur les NICs de backend et en isolant chaque niveau avec son propre NSG

Terminologie importante :

• Groupe cible : Un regroupement logique de cibles enregistrées (IP, port, poids) auxquelles un ALB distribue le trafic ; réutilisable dans les règles de transfert.
• Règle de transfert : Une règle qui lie une interface écouteur IP et port aux cibles, en définissant la façon dont le Load Balancer distribue le trafic client.
• Écouteur : L'interface orientée client d'un Load Balancer qui accepte les connexions sur un IP exposé et un port configuré.
• Groupe de sécurité réseau (NSG) : Un pare-feu étatique, à interdiction totale, attaché par VM ou par NIC, contenant jusqu'à 100 règles.
• Déchargement de TLS : La terminaison de HTTPS à l'ALB et le transfert de HTTP non chiffré vers les backends, en supprimant la gestion des certificats des serveurs d'application.

Prochaines étapes

Continuer l'apprentissage : Unité 2.4 : Provisionnement de 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é