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

Bien que la ressource Kubernetes Ingress standard soit idéale pour provisionner et configurer l'équilibrage de charge Ingress de base, elle n'inclut pas le type de fonctionnalités de personnalisation requises pour rendre Kubernetes de qualité production . Au lieu de cela, les utilisateurs non-NGINX doivent utiliser des annotations, des ConfigMaps et des modèles personnalisés qui sont sujets aux erreurs, difficiles à utiliser, non sécurisés et manquent de portée précise. Les ressources NGINX Ingress sont notre réponse à ce problème.

Les ressources NGINX Ingress sont disponibles pour les versions NGINX Open Source et NGINX Plus de NGINX Ingress Controller. Ils fournissent un style de configuration natif, sécurisé et indenté qui simplifie la mise en œuvre de l’équilibrage de charge Ingress. Dans ce blog, nous nous concentrons sur deux fonctionnalités introduites dans NGINX Ingress Controller 1.11.0 qui facilitent la configuration des politiques WAF et d'équilibrage de charge :

• Ressource TransportServer – La ressource TransportServer définit la configuration pour l’équilibrage de charge TCP, UDP et TLS Passthrough. Nous avons ajouté des contrôles de santé, des rapports d’état et des extraits de configuration pour améliorer l’équilibrage de charge TCP/UDP.
• Stratégie WAF NGINX Ingress – Lorsque vous déployez NGINX App Protect 3.0 avec NGINX Ingress Controller, vous pouvez exploiter les ressources NGINX Ingress pour appliquer des stratégies WAF à des services Kubernetes spécifiques.

Améliorations apportées à la ressource TransportServer

NGINX Ingress Controller 1.11.0 étend la ressource TransportServer (TS) dans les domaines suivants :

• Extraits
• Contrôles de santé
• Prise en charge de plusieurs ressources TS

Note: Les ajouts à la ressource TransportServer dans la version 1.11.0 sont un aperçu technologique en cours de développement actif. Ils seront mis à niveau vers une norme de qualité stable et prête pour la production dans une future version.

Extraits de TransportServer

Dans 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 pour les clients basés sur HTTP. La version 1.11.0 introduit des extraits pour les ressources TS, afin que vous puissiez facilement exploiter toute la gamme des fonctionnalités NGINX et NGINX Plus pour fournir des services basés sur TCP/UDP. Par exemple, vous pouvez utiliser des extraits pour ajouter des directives de refus et d'autorisation qui utilisent des adresses IP et des plages pour définir 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.

Prise en charge de plusieurs ressources TransportServer avec ingressClassName

Lorsque vous mettez à jour et appliquez une ressource TS, il est utile de vérifier que la configuration est valide et a été appliquée avec succès 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 traitée par un déploiement Ingress Controller particulier dans les environnements où vous avez plusieurs déploiements.

Pour afficher l'état d'une ou de toutes les ressources TS, exécutez la commande kubectl get transportserver ; la sortie inclut l'état ( valide ou invalide ), la raison de la mise à jour la plus récente et (pour un seul TS) un message personnalisé.

$ 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

Si plusieurs ressources TS sont en concurrence pour le même hôte/auditeur, NGINX Ingress Controller sélectionne la ressource TS avec les horodatages les plus anciens, garantissant un résultat déterministe dans cette situation.

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

Les ressources NGINX Ingress rendent non seulement la configuration plus simple et plus flexible, mais elles vous permettent également de déléguer le contrôle du trafic à différentes équipes et d'imposer des restrictions de privilèges plus strictes aux utilisateurs propriétaires de sous-routes d'application, comme défini dans les ressources VirtualServerRoute (VSR). En donnant aux bonnes équipes l’accès aux bonnes ressources Kubernetes, les ressources NGINX Ingress vous offrent un contrôle précis sur les ressources réseau et réduisent les dommages potentiels aux applications si les utilisateurs sont compromis ou piratés.

La version 1.11.0 introduit un objet de stratégie de pare-feu d’application Web (WAF) natif pour étendre ces avantages à la configuration de NGINX App Protect dans vos déploiements Kubernetes. La politique exploite les objets APLogConf et APPolicy introduits dans la version 1.8.0 et peut être attachée aux ressources VirtualServer (VS) et VSR. Cela signifie que les administrateurs de sécurité peuvent avoir la propriété de l'ensemble de la configuration Ingress avec les ressources VS, tout en déléguant les responsabilités de sécurité à d'autres équipes en référençant les ressources VSR.

Dans l'exemple suivant, la politique waf-prod est appliquée aux utilisateurs routés vers webapp-prod en amont. Pour déléguer les responsabilités de sécurité pour la route /v2 entre les espaces de noms appartenant à différentes équipes, la directive de route en surbrillance fait référence à 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 de test peuvent définir leurs propres paramètres et politiques WAF à l’aide des ressources VSR dans 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 sépare les locataires par espace de noms et applique une stratégie WAF différente pour le service webapp-test-svc dans l'espace de noms de test . Il illustre comment la délégation de ressources à différentes équipes et leur encapsulation avec des objets simplifient le test de nouvelles fonctionnalités sans perturber 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 lorsque la ressource Ingress est appliquée, le contrôleur Ingress rejette la ressource et supprime la configuration correspondante de 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édéfini 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.