Équilibrage de charge TCP/UDP amélioré et configuration du WAF avec NGINX Ingress Controller

Amir RawdatIngénieur solutions

Bien que la ressource Ingress standard de Kubernetes soit parfaitement adaptée au provisionnement et à la configuration d’un équilibrage de charge Ingress de base, elle n’offre pas les fonctionnalités de personnalisation nécessaires pour rendre Kubernetes adapté à la production. Les utilisateurs qui n’utilisent pas NGINX doivent donc recourir à des annotations, des ConfigMaps et des modèles personnalisés, qui sont sujets aux erreurs, difficiles à utiliser, peu sécurisés et dépourvus de contrôle précis de la portée. Les ressources Ingress de NGINX constituent notre réponse à ce problème.

Les ressources NGINX Ingress sont disponibles pour les versions de NGINX Ingress Controller basées sur NGINX Open Source et NGINX Plus. Elles offrent un style de configuration natif, avec typage sécurisé et indentation, qui simplifie la mise en œuvre de l’équilibrage de charge Ingress. Dans cet article, nous nous intéressons à deux fonctionnalités introduites dans NGINX Ingress Controller 1.11.0 qui facilitent la configuration du WAF et des stratégies d’équilibrage de charge :

• Ressource TransportServer – La ressource TransportServer définit la configuration de l’équilibrage de charge pour TCP, UDP et le relais TLS. Nous avons ajouté des contrôles d’intégrité, des rapports d’état et des extraits de configuration afin d’améliorer l’équilibrage de charge TCP/UDP.
• Politique WAF NGINX Ingress – Lorsque vous déployez NGINX App Protect 3.0 avec NGINX Ingress Controller, vous pouvez utiliser les ressources NGINX Ingress pour appliquer des politiques 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 de configuration
• Contrôles d’intégrité
• Prise en charge de plusieurs ressources TS

Remarque : les ajouts apportés à la ressource TransportServer dans la version 1.11.0 sont proposés en tant qu’aperçu technologique et font l’objet d’un développement actif. Ils atteindront un niveau de qualité stable et adapté à la production dans une prochaine 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 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 de NGINX et NGINX Plus pour fournir des services TCP/UDP. Par exemple, vous pouvez utiliser des extraits pour ajouter les directives deny et allow, qui utilisent des adresses et des plages d’adresses IP pour définir les clients autorisés à accéder à un service

apiVersion: k8s.nginx.org/v1alpha1kind: TransportServer
metadata:
  name: cafe
spec:
  host: cafe.example.com
  serverSnippets: |
    deny  192.168.1.1;
    allow 192.168.1.0/24;
  upstreams:
  - name: tea
    service: tea-svc
    port: 80

Contrôles d’intégrité

Pour surveiller l’état d’un cluster Kubernetes, NGINX Ingress Controller prend non seulement en compte les sondes Kubernetes propres aux pods d’application, mais surveille également l’état du réseau entre les services en amont basés sur TCP/UDP, au moyen de contrôles d’intégrité passifs pour évaluer l’état des transactions en cours et de contrôles d’intégrité actifs (exclusifs à NGINX Plus) pour tester périodiquement les points de terminaison à l’aide de requêtes de connexion synthétiques.

Les contrôles d’intégrité peuvent être très utiles pour la coupure de circuit et la gestion des erreurs applicatives. Vous pouvez personnaliser le contrôle d’intégrité à l’aide des paramètres du champ healthCheck field de la ressource TS, qui permettent de définir l’intervalle entre les sondes, leur délai d’expiration, les délais entre les sondes, et bien plus encore.

En outre, vous pouvez définir le service en amont et le port de destination des sondes d’intégrité provenant de NGINX Ingress Controller. Cette fonctionnalité est utile lorsque l’état de l’application en amont est exposé sur un autre point d’écoute 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 qu’elle a bien été appliquée au déploiement d’Ingress Controller correspondant. La version 1.11.0 introduit le champ ingressClassName ainsi que le signalement de l’état de la ressource TS. Le champ ingressClassName garantit que la ressource TS est traitée par un déploiement d’Ingress Controller spécifique dans les environnements comportant plusieurs déploiements.

Pour afficher l’état d’une ou de toutes les ressources TS, exécutez la commande kubectl get transportserver ; la sortie indique l’état (Valid ou Invalid), la raison de la dernière mise à jour et, pour une seule ressource TS, un message personnalisé.

$ kubectl get transportserver  NAME      STATE   REASON           AGE
  dns-tcp   Valid   AddedOrUpdated   47m

$ kubectl describe transportserver dns-tcp
. . .
Status:
  Message:  Configuration for default/dns-tcp was added or updated
  Reason:   AddedOrUpdated
  State:    Valid

Si plusieurs ressources TS sont en concurrence pour le même hôte/listener, NGINX Ingress Controller sélectionne la ressource TS dont l’horodatage est le plus ancien, garantissant ainsi un résultat déterministe dans cette situation.

Définir 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 responsables des sous-routes d’applications, telles que définies dans les ressources VirtualServerRoute (VSR). En accordant aux équipes appropriées l’accès aux ressources Kubernetes adéquates, les ressources NGINX Ingress vous offrent un contrôle précis des ressources réseau et réduisent les dommages potentiels causés aux applications en cas de compromission ou de piratage des utilisateurs.

La version 1.11.0 introduit un pare-feu d’applications web (WAF) natif sous la forme d’un objet Policy afin d’étendre ces avantages à la configuration de NGINX App Protect dans vos déploiements Kubernetes. Cette stratégie s’appuie sur les objets APLogConf et APPolicy introduits dans la version 1.8.0 et peut être associée aux ressources VirtualServer (VS) et VSR. Ainsi, les administrateurs de la sécurité peuvent gérer l’intégralité de la configuration Ingress à l’aide de ressources VS, tout en déléguant les responsabilités en matière de sécurité à d’autres équipes par le biais de références à des ressources VSR.

Dans l’exemple suivant, la stratégie « waf-prod » est appliquée aux utilisateurs acheminés vers le serveur en amont « webapp-prod ». Afin de déléguer les responsabilités en matière de sécurité pour la route « /v2 » entre des espaces de noms appartenant à différentes équipes, la directive « route » mise en évidence fait référence à une ressource VSR.

apiVersion: k8s.nginx.org/v1kind: VirtualServer
metadata:
  name: webapp
spec:
  host: webapp.example.com
  policies:
  - name: waf-prod 
  tls:
    secret: app-secret
  upstreams:
  - name: webapp-prod
    service: webapp-svc
    port: 80
  routes:
  - path: /v2
    route: test/test
  - path: /v1
    action:
      pass: webapp-prod

Les équipes qui gèrent l’espace de noms « test » peuvent définir leurs propres paramètres et politiques WAF à l’aide des ressources VSR de cet espace de noms.

apiVersion: k8s.nginx.org/v1kind: VirtualServerRoute
metadata:
  name: test 
  namespace: test
spec:
  host: webapp.example.com
  upstreams:
  - name: webapp 
    service: webapp-test-svc
    port: 80
  subroutes:
  - path: /v2
    policies:
    - name: waf-test
    action:
      pass: webapp

Cet exemple sépare les locataires par espace de noms et applique une politique WAF différente au service webapp-test-svc dans l’espace de noms test. Il montre comment la délégation des ressources à différentes équipes et leur encapsulation dans 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é professionnelle, à la fois flexible, puissant et facile à utiliser. Outre les améliorations apportées au WAF et à TS, la version 1.11.0 comprend les améliorations suivantes :

• Validation d’un plus grand nombre d’annotations – Évitez davantage d’erreurs de configuration
• Informations sur l’état des politiques – Afficher l’état des objets « Policy » avant leur application à la configuration Ingress
• Compatibilité avec Istio – Exploitez les fonctionnalités avancées du contrôleur Ingress 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 Ingress NGINX avec les adresses IP de service/cluster

Validation d’annotations supplémentaires

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

Validation des annotationsnginx.org/client-max-body-size Doit être un décalage validenginx.org/fail-timeout Doit être une durée validenginx.org/max-conns Doit être un entier positif ou nul validenginx.org/max-fails Doit être un entier positif ou nul validenginx.org/proxy-buffer-size Doit être une taille validenginx.org/proxy-buffers Doit être une spécification de tampon de proxy validenginx.org/proxy-connect-timeout Doit être une durée validenginx.org/proxy-max-temp-file-size Doit être une taille validenginx.org/proxy-read-timeout Doit être une durée validenginx.org/proxy-send-timeout Doit être une durée validenginx.org/upstream-zone-size Doit être une taille valide

Si la valeur de l’annotation n’est pas valide lors de l’application de la ressource Ingress, l’Ingress Controller rejette la ressource et supprime la configuration correspondante de NGINX.

Informations d’état sur les stratégies

La commande « kubectl get policy » indique désormais l’état de la stratégie (Valide ou Non valide) et, pour un seul TS, un message personnalisé ainsi que la raison de la dernière mise à jour.

$ kubectl get policy  NAME              STATE   AGE
  webapp-policy     Valid   30s

$ kubectl describe policy webapp-policy
. . .
Status:
  Message:  Configuration for default/webapp-policy was added or updated
  Reason:   AddedOrUpdated
  State:    Valid

Compatibilité avec Istio

NGINX Ingress Controller peut désormais être utilisé comme contrôleur Ingress pour les applications exécutées au sein d’un maillage de services Istio. Les utilisateurs peuvent ainsi continuer à bénéficier des fonctionnalités avancées offertes par NGINX Ingress Controller dans les environnements basés sur Istio, sans avoir recours à des solutions de contournement. Cette intégration implique deux exigences :

• L’injection d’un side-car Istio dans le déploiement de NGINX Ingress Controller
• Un seul en-tête HTTP Host est envoyé au backend

Pour satisfaire à la première exigence, ajoutez les éléments suivants au champ 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 grâce à une modification du comportement du champ requestHeaders. Dans les versions précédentes, avec la configuration suivante, deux en-têtes Host étaient envoyés au serveur backend : $host et la valeur spécifiée, bar.example.com.

apiVersion: k8s.nginx.org/v1kind: VirtualServer
metadata:
  name: foo 
spec:
  host: foo.example.com
  upstreams:
  - name: foo
    port: 8080
    service: backend-svc
    use-cluster-ip: true
  routes:
  - path: "/"
    action:
      proxy:
        upstream: foo
        requestHeaders: set: - name: Host value: bar.example.com

À partir de la version 1.11.0, 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 de NGINX Ingress Controller peuvent désormais être renseignés avec les adresses IP des services ou du cluster, au lieu des adresses IP individuelles des points de terminaison des pods. Pour permettre à NGINX Ingress Controller d’acheminer le trafic vers les services Cluster-IP, ajoutez le champ « use-cluster-ip: true » dans la section upstreams de votre configuration VS ou VSR :

upstreams:  - name: tea
    service: tea-svc
    port: 80
    use-cluster-ip: true
  - name: coffee
    service: coffee-svc
    port: 80
    use-cluster-ip: true

Ressources

Pour consulter la liste complète des modifications de la version 1.11.0, reportez-vous aux notes de version.

Pour essayer NGINX Ingress Controller pour Kubernetes avec NGINX Plus et NGINX App Protect, commencez 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 une image de conteneur précompilée depuis DockerHub.

Pour en savoir plus sur les différences entre les contrôleurs Ingress, consultez l’article « Attendez, quel contrôleur NGINX Ingress pour Kubernetes suis-je en train d’utiliser ? » sur notre blog.

À propos de l’auteur

Amir RawdatIngénieur solutions

Autres articles de Amir Rawdat