Équilibrage de charge TCP/UDP amélioré et configuration WAF avec le contrôleur d'entrée NGINX

La ressource Kubernetes Ingress standard vous permet de gérer et configurer l’équilibrage de charge Ingress basique, mais elle ne propose pas les fonctionnalités de personnalisation indispensables pour rendre Kubernetes adapté à la production. Les utilisateurs d’autres solutions que NGINX doivent alors se contenter d’annotations, de ConfigMaps et de modèles personnalisés, qui sont sources d’erreurs, complexes à utiliser, peu sûrs, et manquent de granularité. Les ressources NGINX Ingress répondent précisément à ce besoin.

Les ressources NGINX Ingress sont accessibles pour les versions NGINX Open Source et NGINX Plus du contrôleur NGINX Ingress. Elles offrent un style de configuration natif, type-safe et indenté, qui facilite la mise en place de l'équilibrage de charge Ingress. Dans ce blog, nous mettons en avant deux fonctionnalités introduites dans NGINX Ingress Controller 1.11.0 qui simplifient la configuration des politiques WAF et d'équilibrage de charge :

• Ressource TransportServer – La ressource TransportServer décrit la configuration pour l’équilibrage de charge TCP, UDP et TLS Passthrough. Nous avons intégré des contrôles d’état, des rapports de statut et des extraits de configuration pour optimiser l’équilibrage de charge TCP/UDP.
• Politique WAF NGINX Ingress – En déployant NGINX App Protect 3.0 avec NGINX Ingress Controller, vous utilisez les ressources NGINX Ingress pour appliquer des politiques WAF à des services Kubernetes précis.

Améliorations de la ressource TransportServer

NGINX Ingress Controller 1.11.0 améliore la ressource TransportServer (TS) dans les aspects suivants :

• Extraits
• Contrôles de santé
• Gestion de plusieurs ressources TS

Remarque : Les ajouts à la ressource TransportServer dans la version 1.11.0 représentent un aperçu technologique encore en plein développement. Nous vous garantissons qu'ils évolueront vers une qualité stable, prête pour la production, dans une prochaine version.

Extraits de TransportServer

Avec NGINX Ingress Controller, nous avons introduit des extraits de configuration pour les ressources VirtualServer et VirtualServerRoute (VS et VSR) qui vous permettent d’étendre nativement les configurations NGINX Ingress destinées aux clients HTTP. La version 1.11.0 ajoute des extraits pour les ressources TS, vous offrant ainsi la possibilité d’exploiter pleinement les fonctionnalités de NGINX et NGINX Plus pour assurer la livraison de services basés sur TCP/UDP. Par exemple, vous pouvez utiliser des extraits pour insérer les directives deny et allow, qui reposent sur des adresses IP et des plages, afin de contrôler quels clients peuvent accéder à un service

Version de l'API : k8s.nginx.org/v1alpha1kind : TransportServer
métadonnées :
nom : café
spécification :
hôte : café.exemple.com
extraits de serveur : |
refuser 192.168.1.1 ;
autoriser 192.168.1.0/24 ;
amont :
- nom : thé
service : thé-svc
port : 80

Contrôles de santé

Pour surveiller l'état de santé d'un cluster Kubernetes, NGINX Ingress Controller prend non seulement en compte les sondes Kubernetes locales aux pods d'application, mais surveille également l'état du réseau entre les services en amont basés sur TCP/UDP, avec des contrôles de santé passifs pour évaluer l'état de santé des transactions en cours et des contrôles de santé actifs (exclusifs à NGINX Plus) pour sonder périodiquement les points de terminaison avec des demandes de connexion synthétiques.

Les contrôles de santé peuvent être très utiles pour couper les circuits et gérer les erreurs d'application. Vous pouvez personnaliser le contrôle d'intégrité à l'aide de paramètres dans le champ healthCheck de la ressource TS qui définissent l'intervalle entre les sondes, le délai d'expiration de la sonde, les délais entre les sondes, etc.

De plus, vous pouvez définir le service en amont et la destination du port des sondes d’intégrité à partir de NGINX Ingress Controller. Cela est utile dans les situations où l’état de santé de l’application en amont est exposé sur un écouteur différent par un autre processus ou sous-système qui surveille plusieurs composants en aval de l’application.

Gérez plusieurs ressources TransportServer avec ingressClassName

Lorsque vous mettez à jour et appliquez une ressource TS, vérifiez que la configuration est valide et qu’elle a été correctement appliquée au déploiement du contrôleur d’entrée correspondant. La version 1.11.0 introduit le champ ingressClassName et le rapport d’état pour la ressource TS. Le champ ingressClassName garantit que la ressource TS est prise en charge par un déploiement particulier du contrôleur d’entrée dans les environnements avec plusieurs déploiements.

Pour afficher le statut d'une ou de toutes les ressources TS, lancez la commande kubectl get transportserver ; vous obtiendrez l'état (Valide ou Invalide), la raison de la dernière mise à jour, ainsi qu’un message personnalisé pour un TS unique.

$ kubectl get transportserver NOM ÉTAT RAISON ÂGE dns-tcp Valide Ajouté ou mis à jour 47 m $ kubectl describe transportserver dns-tcp . . .
Statut:
  Message:  La configuration de default/dns-tcp a été ajoutée ou mise à jour Raison :   État ajouté ou mis à jour :    Valide

Lorsque plusieurs ressources TS réclament le même hôte/écouteur, NGINX Ingress Controller choisit la ressource TS avec l'horodatage le plus ancien pour garantir un résultat clair et prévisible.

Définition d'une politique WAF avec prise en charge native de NGINX App Protect

Les ressources NGINX Ingress simplifient la configuration tout en offrant plus de flexibilité. Elles vous permettent aussi de déléguer le contrôle du trafic à différentes équipes et d’imposer des restrictions de privilèges plus strictes aux utilisateurs responsables des sous-routes d’applications, selon les ressources VirtualServerRoute (VSR). En attribuant aux bonnes équipes l’accès aux ressources Kubernetes pertinentes, NGINX Ingress vous assure un contrôle granulaire des ressources réseau et limite les risques pour vos applications en cas de compromission ou de piratage des utilisateurs.

La version 1.11.0 introduit un objet natif Policy de pare-feu applicatif web (WAF) pour étendre ces avantages à la configuration de NGINX App Protect dans vos déploiements Kubernetes. Cette policy utilise les objets APLogConf et APPolicy introduits dans la version 1.8.0 et peut s’attacher aux ressources VirtualServer (VS) et VSR. Ainsi, vous pouvez gérer entièrement la configuration Ingress avec les ressources VS, tout en confiant les responsabilités de sécurité à d’autres équipes via les ressources VSR.

Dans l'exemple ci-dessous, la politique waf-prod s'applique aux utilisateurs dirigés vers l’upstream webapp-prod. Pour transférer les responsabilités de sécurité de la route /v2 entre des namespaces gérés par différentes équipes, la directive route mise en évidence renvoie à une ressource VSR.

Version de l'API : k8s.nginx.org/v1kind : Métadonnées du serveur virtuel : nom : webapp spec : hôte : webapp.example.com stratégies : - nom : waf-prod tls : secret : app-secret upstreams : - nom : webapp-prod service : webapp-svc port : 80 routes : - chemin : /v2 route : test/test - chemin : /v1 action : pass : webapp-prod

Les équipes qui gèrent l’espace de noms test peuvent définir leurs propres paramètres et politiques Advanced WAF en utilisant les ressources VSR de cet espace de noms.

Version de l'API : k8s.nginx.org/v1kind : VirtualServerRoute
métadonnées :
nom : test 
espace de noms : test
spécification :
hôte : webapp.example.com
flux en amont :
- nom : webapp 
service : webapp-test-svc
port : 80
sous-routes :
- chemin : /v2
politiques :
- nom : waf-test
action :
passe : webapp

Cet exemple segmente les locataires par espace de noms et applique une politique WAF distincte pour le service webapp-test-svc dans l’espace de noms test. Il montre comment confier des ressources à différentes équipes et les encapsuler dans des objets facilite les tests de nouvelles fonctionnalités sans impacter les applications en production.

Quelles sont les autres nouveautés de la version 1.11.0 ?

Avec NGINX Ingress Controller 1.11.0, nous poursuivons notre engagement à fournir un contrôleur Ingress de qualité industrielle, flexible, puissant et facile à utiliser. Outre les améliorations apportées au WAF et au TS, la version 1.11.0 inclut les améliorations suivantes :

• Validation de davantage d’annotations – Évitez davantage d’erreurs de configuration
• Informations sur l’état de la stratégie – Affiche l’état des objets de stratégie avant qu’ils ne soient appliqués à la configuration d’entrée
• Compatibilité Istio – Exploitez les fonctionnalités avancées du contrôleur d'entrée NGINX dans un environnement Istio
• Adresses IP de cluster pour les points de terminaison en amont – Renseignez les points de terminaison en amont dans la configuration du contrôleur d'entrée NGINX avec les adresses IP de service/cluster

Validation de plus d'annotations

En nous appuyant sur les améliorations apportées à la validation des annotations introduites dans la version 1.10.0, nous validons désormais les annotations supplémentaires suivantes :

Si la valeur de l'annotation n’est pas valide lors de l’application de la ressource Ingress, le contrôleur Ingress rejette la ressource et supprime la configuration correspondante dans NGINX.

Informations sur l'état des politiques

La commande kubectl get policy signale désormais l'état de la politique ( valide ou non valide ) et (pour un seul TS) un message personnalisé et la raison de la mise à jour la plus récente.

$ kubectl get policy NOM ÉTAT ÂGE webapp-policy Valide 30 s $ kubectl describe policy webapp-policy . . .
Statut:
  Message:  La configuration de default/webapp-policy a été ajoutée ou mise à jour Raison :   État ajouté ou mis à jour :    Valide

Compatibilité avec Istio

NGINX Ingress Controller peut désormais être utilisé comme contrôleur d’entrée pour les applications exécutées dans un maillage de service Istio. Cela permet aux utilisateurs de continuer à utiliser les fonctionnalités avancées fournies par NGINX Ingress Controller sur les environnements basés sur Istio sans recourir à des solutions de contournement. Cette intégration implique deux exigences :

• L'injection d'un sidecar Istio dans le déploiement du contrôleur d'entrée NGINX
• Un seul en-tête d'hôte HTTP est envoyé au backend

Pour satisfaire à la première exigence, incluez les éléments suivants dans le champ d’annotations de votre fichier de déploiement NGINX Ingress.

annotations : traffic.sidecar.istio.io/includeInboundPorts : "" 
traffic.sidecar.istio.io/excludeInboundPorts : « 80 443 » traffic.sidecar.istio.io/excludeOutboundIPRanges : "10.90.0.0/16,10.45.0.0/16" sidecar.istio.io/inject: 'true'

La deuxième exigence est satisfaite par une modification du comportement du champ requestHeaders . Dans les versions précédentes, avec la configuration suivante, deux en-têtes d'hôte étaient envoyés au backend : $host et la valeur spécifiée, bar.example.com .

Version de l'API : k8s.nginx.org/v1kind : Métadonnées du serveur virtuel : nom : foo spécification : hôte : foo.example.com amont : - nom : foo port : 8080 service : backend-svc use-cluster-ip : true routes : - chemin : « / » action : proxy : en amont : foo requestHeaders : set : - nom : Valeur de l'hôte : bar.example.com

Dans la version 1.11.0 et ultérieure, seule la valeur spécifiée est envoyée. Pour envoyer $host , omettez entièrement le champ requestHeaders .

Adresses IP de cluster pour les points de terminaison en amont

Les points de terminaison en amont dans la configuration du contrôleur d’entrée NGINX peuvent désormais être renseignés avec des adresses IP de service/cluster, au lieu des adresses IP individuelles des points de terminaison de pod. Pour permettre à NGINX Ingress Controller d'acheminer le trafic vers les services Cluster-IP, incluez le champ use-cluster-ip: true dans la section upstreams de votre configuration VS ou VSR :

en amont : - nom : service de thé : tea-svc port : 80 use-cluster-ip: true - nom: service café: port coffee-svc: 80 utilisation-cluster-ip : vrai

Ressources

Pour le journal des modifications complet de la version 1.11.0, consultez les Notes de version .

Pour essayer NGINX Ingress Controller pour Kubernetes avec NGINX Plus et NGINX App Protect, démarrez votre essai gratuit de 30 jours dès aujourd'hui ou contactez-nous pour discuter de vos cas d'utilisation .

Pour essayer NGINX Ingress Controller avec NGINX Open Source, vous pouvez obtenir le code source de la version ou télécharger un conteneur préassemblé depuis DockerHub.

Pour une discussion sur les différences entre les contrôleurs d'entrée, consultez Attendez, quel contrôleur d'entrée NGINX pour Kubernetes suis-je en train d'utiliser ? sur notre blog.