Nouveautés HAProxy : OpenTelemetry, JWT Natif, et Optimisations de Performance

Publié le : 15/04/2025 à 09:00 Mis à jour le : 08/07/2026 à 12:34 Vues : 508

1. Observabilité Native avec OpenTelemetry

HAProxy s'intègre désormais parfaitement dans les écosystèmes d'observabilité modernes grâce à la prise en charge native du protocole OTLP.

Concept

Auparavant, tracer les requêtes à travers HAProxy nécessitait des agents ou des sidecars. Désormais, HAProxy peut générer et exporter des traces distribuées nativement au format OpenTelemetry (OTLP). Chaque requête passant par HAProxy peut être enrichie d'un contexte de trace (span), permettant une visibilité de bout en bout depuis l'edge jusqu'à vos microservices.

Cas d'utilisation et configuration

Cas d'utilisation : Diagnostiquer la latence dans une architecture microservices. En visualisant la trace complète dans un outil comme Jaeger ou Grafana Tempo, vous pouvez immédiatement voir si le temps est passé dans HAProxy, sur le réseau, ou dans un service backend spécifique.

Configuration :

# /etc/haproxy/haproxy.cfg

global
    # Définir l'endpoint du collecteur OpenTelemetry
    otel-collector otel_collector_1
        address 10.0.1.10:4317
        protocol grpc

frontend http_in
    bind *:80
    # Activer la génération de traces pour ce frontend
    option otel-trace
    otel-trace-collector otel_collector_1

    default_backend my_app

backend my_app
    # Activer la génération de traces pour le backend également
    option otel-trace
    otel-trace-collector otel_collector_1
    server app1 192.168.1.10:8080

Avec cette configuration, HAProxy génère un span pour la partie frontend (temps de traitement entrant) et un autre pour la partie backend (temps d'attente de la réponse du serveur), puis les exporte vers votre collecteur.

2. Validation JWT Native à l'Edge

Sécurisez vos APIs directement depuis HAProxy, sans dépendances externes.

Concept

La validation des JSON Web Tokens (JWT) est une tâche courante pour sécuriser les APIs. HAProxy peut désormais valider la signature et les claims (comme la date d'expiration `exp`) d'un JWT de manière native. Cela permet de rejeter les requêtes non authentifiées ou invalides à la périphérie du réseau, protégeant ainsi vos applications et réduisant la charge sur vos services d'authentification.

Cas d'utilisation et configuration

Cas d'utilisation : Protéger un ensemble de microservices qui attendent un JWT valide. Seules les requêtes avec un token valide et non expiré sont autorisées à passer.

Configuration :

# /etc/haproxy/haproxy.cfg

global
    # Charger la clé publique pour la validation de la signature (ici, ES256)
    jwt-load-key es256-key /etc/haproxy/public_key.pem alg ES256

frontend api_gateway
    bind *:443 ssl crt /etc/ssl/mycert.pem
    http-request deny unless { req.auth.bearer.jwt_verify(es256-key) -m bool }
    http-request deny if { req.auth.bearer.jwt_claim(exp) -m int,le `date` }

    # Extraire le 'sub' (sujet) du JWT pour le logging ou le routage
    http-request set-var(txn.user_id) req.auth.bearer.jwt_claim(sub)

    default_backend protected_api

Cette configuration effectue deux vérifications cruciales : la validité de la signature du token, puis sa date d'expiration, avant de laisser passer la requête.

3. Multi-threading 2.0 et Smarter Buffers

Des optimisations internes profondes pour une performance et une efficacité accrues.

Multi-threading 2.0

Le modèle de multi-threading a été entièrement repensé. Auparavant, une connexion était liée à un thread spécifique de sa création à sa destruction. Le nouveau modèle permet aux tâches d'une même connexion (lecture, traitement, écriture) d'être réparties sur différents threads disponibles. Cela conduit à une bien meilleure répartition de la charge, une réduction de la latence et une scalabilité quasi-linéaire même avec un grand nombre de cœurs CPU.

global
    # Activer le multi-threading avec 16 threads
    nbthread 16

Smarter Buffers

HAProxy introduit une gestion des tampons (buffers) plus intelligente et dynamique. Au lieu d'allouer des tampons de taille fixe, il ajuste leur taille en fonction des besoins réels du trafic (taille des requêtes et des réponses). Cela réduit considérablement la consommation de mémoire, en particulier dans les scénarios avec des milliers de connexions simultanées, tout en évitant les copies de données inutiles pour une latence plus faible.

4. HTTP/1 Glitch Detector

Une protection robuste contre les attaques de type 'Request Smuggling'.

Concept et utilité

Le 'HTTP Request Smuggling' est une technique d'attaque qui exploite les incohérences d'interprétation des requêtes HTTP/1.1 entre un proxy et le serveur backend. Le 'Glitch Detector' de HAProxy analyse le trafic HTTP/1 à la recherche d'ambiguïtés (par exemple, la présence simultanée des en-têtes `Content-Length` et `Transfer-Encoding`). Si une telle anomalie est détectée, HAProxy peut bloquer la requête ou la normaliser pour protéger les serveurs en aval.

Configuration :

# /etc/haproxy/haproxy.cfg

defaults
    # Activer la détection et le rejet des requêtes ambiguës
    option http-glitch-detect reject

Cette simple option renforce considérablement la sécurité de votre pile applicative contre une classe d'attaques sophistiquées.

Conclusion

HAProxy continue d'innover pour répondre aux exigences des infrastructures modernes.

Un outil tourné vers l'avenir

Ces nouveautés confirment le statut de HAProxy comme un outil de premier plan pour le load balancing. En intégrant nativement des fonctionnalités d'observabilité (OpenTelemetry) et de sécurité (JWT, Glitch Detector) tout en optimisant ses performances internes (Multi-threading 2.0), HAProxy permet de construire des architectures plus résilientes, sécurisées et performantes.