Guide pour choisir un contrôleur d'entrée, partie 2 : Risques et pérennité

Rédacteur – Ce billet fait partie d’ une série en 10 parties :

1. Réduisez la complexité avec Kubernetes de niveau production
2. Comment améliorer la résilience dans Kubernetes grâce à la gestion avancée du trafic
3. Comment améliorer la visibilité dans Kubernetes
4. Six façons de sécuriser Kubernetes à l'aide d'outils de gestion du trafic
5. Guide pour choisir un contrôleur d'entrée, partie 1 : Identifiez vos besoins
6. Guide pour choisir un contrôleur d'entrée, partie 2 : Risques et pérennité (ce billet)
7. Guide pour choisir un contrôleur d'entrée, partie 3 : Open Source contre Par défaut vs. Commercial
8. Guide pour choisir un contrôleur d'entrée, partie 4 : Options du contrôleur d'entrée NGINX
9. Comment choisir un maillage de services
10. Test des performances des contrôleurs d'entrée NGINX dans un environnement cloud Kubernetes dynamique

Vous pouvez également télécharger l’ensemble complet des blogs sous forme d’eBook gratuit – Taking Kubernetes from Test to Production .

Dans la partie 1 de notre guide pour choisir un contrôleur Ingress , nous avons expliqué comment identifier vos besoins. Mais il n’est pas encore temps de tester les produits ! Dans cet article, nous expliquons comment un mauvais contrôleur d'entrée peut ralentir votre vitesse de publication et même vous faire perdre des clients. Comme tout outil, les contrôleurs Ingress peuvent introduire des risques et avoir un impact sur l’évolutivité future. Voyons comment éliminer les choix qui pourraient causer plus de mal que de bien.

Risques liés au contrôleur d'entrée

Il existe trois risques spécifiques à prendre en compte lors de l’introduction d’un outil de gestion du trafic pour Kubernetes : la complexité, la latence et la sécurité. Ces problèmes sont souvent étroitement liés ; lorsqu’un problème est présent, il est probable que vous verrez les autres. Chacun peut être introduit par un contrôleur d’entrée et c’est à votre organisation de décider si le risque est tolérable. Les consommateurs d’aujourd’hui sont capricieux et tout ce qui entraîne une mauvaise expérience numérique peut être inacceptable malgré un ensemble de fonctionnalités convaincantes.

La complexité va-t-elle à l’encontre de l’objectif d’une architecture de microservices ?

Les meilleurs outils Kubernetes sont ceux qui répondent aux objectifs de l’architecture des microservices : légers et simples dans leur conception. Il est possible de développer un contrôleur Ingress très riche en fonctionnalités qui respecte ces principes, mais ce n’est pas toujours la norme. Certains concepteurs incluent trop de fonctions ou utilisent des scripts alambiqués pour ajouter des fonctionnalités qui ne sont pas natives du moteur sous-jacent, ce qui donne lieu à un contrôleur Ingress inutilement complexe.

Et pourquoi est-ce important ? Dans Kubernetes, un outil trop complexe peut avoir un impact négatif sur les performances de l’application et limiter votre capacité à faire évoluer votre déploiement horizontalement. Vous pouvez généralement repérer un contrôleur Ingress trop complexe par sa taille : plus l’empreinte est grande, plus l’outil est complexe.

Latence – Le contrôleur d’entrée ralentit-il vos applications ?

Les contrôleurs d’ingress peuvent ralentir les performances à cause de la consommation de ressources, des erreurs et des délais d’attente. Évaluez la latence ajoutée pour les déploiements statiques comme dynamiques, et éliminez les solutions qui dépassent la latence tolérée selon vos critères internes. Pour comprendre comment les reconfigurations influent sur la vitesse des applications, consultez Performance Testing NGINX Ingress Controllers in a Dynamic Kubernetes Cloud Environment sur notre blog.

Sécurité – Le contrôleur d’entrée ouvre-t-il la porte aux pirates informatiques ?

Les vulnérabilités et expositions courantes (CVE) sont monnaie courante sur Internet aujourd’hui, et le temps nécessaire à votre fournisseur de contrôleur Ingress pour fournir un correctif CVE peut faire la différence entre la sécurité et une violation. En fonction de la tolérance au risque de votre organisation, vous souhaiterez peut-être éliminer les solutions qui prennent plus de quelques jours (ou au plus quelques semaines) pour fournir des correctifs.

Au-delà des CVE, certains contrôleurs Ingress vous exposent à une autre vulnérabilité potentielle. Imaginez : vous travaillez pour un détaillant en ligne et vous avez besoin d’aide pour résoudre la configuration de votre contrôleur Ingress open source. Le support commercial n’est pas accessible, alors vous postez le problème sur un forum comme Stack Overflow. Quelqu’un propose son aide et souhaite examiner les fichiers de configuration et de logs du contrôleur Ingress ainsi que d’autres composants Kubernetes. Pressé de régler rapidement le problème, vous partagez les fichiers.

Le « bon Samaritain » vous aide à résoudre votre problème, mais six mois plus tard, vous découvrez une faille : des numéros de carte de crédit ont été volés dans vos dossiers clients. Oups. Il s'avère que les fichiers que vous avez partagés contenaient des informations qui ont été utilisées pour infiltrer votre application. Ce scénario illustre l'une des principales raisons pour lesquelles les organisations choisissent de payer pour obtenir de l'aide : cela garantit la confidentialité.

Remarque sur les contrôleurs d'entrée basés sur OpenResty

OpenResty est une plateforme Web basée sur NGINX Open Source qui intègre LuaJIT, des scripts Lua et des modules NGINX tiers pour étendre les fonctionnalités de NGINX Open Source. À leur tour, il existe plusieurs contrôleurs Ingress basés sur OpenResty, ce qui, selon nous, pourrait potentiellement ajouter deux risques par rapport à nos contrôleurs Ingress basés sur NGINX Open Source et NGINX Plus :

• Délais d’attente – Comme indiqué, OpenResty utilise des scripts Lua pour implémenter des fonctionnalités avancées comme celles de notre contrôleur d’entrée commercial basé sur NGINX Plus . L’une de ces fonctionnalités est la reconfiguration dynamique, qui élimine une exigence Open Source NGINX qui réduit la disponibilité, à savoir que la configuration NGINX doit être rechargée lorsque les points de terminaison de service changent. Pour réaliser une reconfiguration dynamique avec OpenResty, le gestionnaire Lua choisit le service en amont vers lequel acheminer la requête, éliminant ainsi le besoin de recharger la configuration NGINX.

  Cependant, Lua doit vérifier en permanence les modifications des backends, ce qui consomme des ressources. Le traitement des requêtes entrantes prend plus de temps, ce qui bloque certaines d’entre elles et augmente les risques de temporisation. À mesure que vous augmentez le nombre d’utilisateurs et de services, le fossé entre les requêtes entrantes par seconde et celles que Lua peut gérer s’élargit exponentiellement. Cela engendre une latence, une complexité accrue et des coûts supérieurs.

  Lisez Tests de performances des contrôleurs d'entrée NGINX dans un environnement cloud Kubernetes dynamique pour voir combien de latence Lua peut ajouter.

• Retards de mise à jour des correctifs CVE – Par rapport aux contrôleurs Ingress de NGINX, les correctifs pour les CVE prennent inévitablement plus de temps à apparaître dans les contrôleurs Ingress basés sur des outils comme OpenResty qui sont à leur tour basés sur NGINX Open Source. Comme nous le décrivons en détail dans Atténuer rapidement et facilement les vulnérabilités de sécurité avec NGINX Plus , lorsqu'un CVE est découvert dans NGINX, nous, en tant que fournisseur, sommes généralement informés avant que le CVE ne soit divulgué publiquement. Cela nous permet de publier un correctif pour NGINX Open Source et NGINX Plus dès que le CVE est annoncé.

  Les technologies basées sur NGINX Open Source pourraient ne pas être informées de la CVE avant ce moment-là, et d'après notre expérience, les correctifs OpenResty sont considérablement en retard par rapport aux nôtres ( quatre mois dans un cas récent) . Les correctifs pour un contrôleur Ingress basé sur OpenResty prennent inévitablement encore plus de temps, ce qui donne à un mauvais acteur de nombreuses opportunités d'exploiter la vulnérabilité.

Assurez l'avenir de votre contrôleur d'entrée

Même si vous commencez tout juste à vous familiariser avec Kubernetes, il y a de fortes chances que vous aspiriez à le mettre en production un jour. Il existe quatre domaines principaux dans lesquels vos besoins sont susceptibles d’augmenter au fil du temps : l’infrastructure, la sécurité, le support et le multi-locataire.

Infrastructure – Allez-vous utiliser Kubernetes dans des environnements hybrides ou multicloud ?

Il est rare qu’une organisation s’engage pleinement et de manière permanente dans un seul type d’environnement. Le plus souvent, les organisations disposent d’un mélange de locaux et de cloud, qui peut inclure des clouds privés, publics, hybrides et multiclouds. (Pour une analyse plus approfondie des différences entre ces environnements, lisez Quelle est la différence entre le multicloud et le cloud hybride ? ).

Comme nous l'avons mentionné dans la partie 1 de cette série, il est tentant de choisir des outils fournis par défaut avec chaque environnement, mais il existe une multitude de problèmes spécifiques aux contrôleurs Ingress par défaut. Nous aborderons tous les inconvénients dans la partie 3 de la série, mais le problème le plus pertinent pour la pérennité est le verrouillage fournisseur : vous ne pouvez pas utiliser un contrôleur Ingress spécifique au cloud dans tous vos environnements. L’utilisation d’outils spécifiques au cloud par défaut a un impact sur votre capacité à évoluer, car il ne vous reste que deux alternatives peu attrayantes :

1. Essayez de faire fonctionner le cloud existant pour tous vos besoins
2. Réécrivez toutes vos configurations – pas seulement l'équilibrage de charge, mais aussi la sécurité !  – pour le contrôleur Ingress dans chaque nouvel environnement

Si la première alternative n’est souvent pas viable pour des raisons commerciales, la seconde est également délicate car elle entraîne une prolifération d’outils, ouvre de nouvelles vulnérabilités en matière de sécurité et oblige vos employés à franchir des courbes d’apprentissage abruptes. La troisième alternative, et la plus efficace, consiste à choisir dès le départ un contrôleur Ingress indépendant de l’infrastructure, vous permettant d’utiliser le même outil dans tous vos environnements.

En matière d’infrastructure, il y a un autre élément à prendre en compte : les certifications. Prenons l’exemple de Red Hat OpenShift Container Platform (OCP). Si vous êtes un utilisateur OCP, vous savez probablement déjà que Red Hat Marketplace propose des opérateurs certifiés pour OCP, notamment l' opérateur NGINX Ingress . Les normes de certification de Red Hat vous garantissent une tranquillité d'esprit en sachant que l'outil fonctionne avec votre déploiement et peut même inclure un support conjoint de Red Hat et du fournisseur. De nombreuses organisations ont l'obligation d'utiliser des outils certifiés pour des raisons de sécurité et de stabilité. Par conséquent, même si vous n'êtes qu'en phase de test pour le moment, il est utile de garder à l'esprit les exigences de votre entreprise en matière d'environnements de production.

Sécurité – Comment allez-vous sécuriser Kubernetes de l’intérieur ?

L’époque où la sécurité du périmètre suffisait à elle seule à assurer la sécurité des applications et des clients est révolue. Les applications Kubernetes sont mieux protégées lorsque la sécurité, y compris l’authentification et l’autorisation, est proche des applications. Et comme les organisations imposent de plus en plus le chiffrement de bout en bout et adoptent un modèle de réseau Zero Trust au sein de Kubernetes, un maillage de services pourrait faire partie de votre avenir.

Quel est le rapport avec votre contrôleur Ingress ? Beaucoup! Centraliser la sécurité (authentification, autorisation, protection DoS, pare-feu d'application Web) au point d'entrée est très judicieux du point de vue du coût et de l'efficacité. Et même si la plupart des maillages de services peuvent être intégrés à la plupart des contrôleurs Ingress, la manière dont ils s’intègrent est très importante. Un contrôleur d'entrée qui s'aligne sur votre stratégie de sécurité peut éviter de gros maux de tête tout au long de votre parcours de développement d'applications.

Pour plus de détails sur les risques liés à la diffusion d’applications cloud natives et sur le déploiement de services d’application dans Kubernetes, partie 2, consultez Sécuriser les applications cloud natives sans perdre de vitesse pour en savoir plus sur les facteurs qui déterminent le meilleur emplacement pour les outils de sécurité.

Soutien – Dans quelle mesure pouvez-vous vous permettre d’être « seul » ?

Lorsque les équipes expérimentent simplement Kubernetes, le support, qu’il provienne de la communauté ou d’une entreprise, n’est souvent pas la priorité absolue. Cela ne pose aucun problème si vos équipes disposent de beaucoup de temps pour trouver leurs propres solutions et solutions de contournement, mais ce n’est pas tenable lorsque vous passez à la production. Même si vous n’avez pas besoin d’assistance aujourd’hui, il peut être judicieux de choisir un contrôleur Ingress qui vous permet d’ajouter de l’assistance à l’avenir ou qui dispose d’un niveau d’assistance peu coûteux qui peut être mis à niveau à mesure que vous évoluez.

Multi-Tenancy – Comment plusieurs équipes et applications peuvent-elles partager un environnement de conteneur de manière sûre et sécurisée ?

Au commencement, il y avait une équipe et une application… n’est-ce pas ainsi que commence toute histoire ? L’histoire continue souvent avec cette équipe qui développe avec succès sa propre application Kubernetes, conduisant l’organisation à exécuter davantage de services sur Kubernetes. Et bien sûr, plus de services = plus d’équipes = plus de complexité.

Pour maximiser votre efficacité, adoptez la multi-utilisation et un modèle Kubernetes qui garantit l'accès et l'isolation exigés par vos processus métier, tout en fournissant la stabilité et les contrôles indispensables pour vos opérateurs. Certains contrôleurs d'Ingress vous permettent de segmenter ces clusters via plusieurs fonctionnalités et concepts : ingresses multiples, classes, namespaces, et ressources ciblées qui prennent en charge la mise en place de contrôles d'accès basés sur les rôles (RBAC).

Étape suivante : Affiner les options

Maintenant que vous avez réfléchi à vos besoins, à votre tolérance au risque et à votre pérennité, vous disposez de suffisamment d’informations pour commencer à affiner le champ très vaste des contrôleurs Ingress. Décomposer ce champ par catégorie peut vous aider à réaliser rapidement cette étape. Dans la troisième partie de notre série, nous explorerons trois catégories différentes de contrôleurs Ingress, y compris les avantages et les inconvénients de chacune.