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’entrée peuvent ajouter de la latence en raison de l’utilisation des ressources, des erreurs et des délais d’attente. Examinez la latence ajoutée dans les déploiements statiques et dynamiques et éliminez les options qui introduisent une latence inacceptable en fonction de vos exigences internes. Pour plus de détails sur la manière dont les reconfigurations peuvent avoir un impact sur la vitesse des applications, consultez Tests de performances des contrôleurs d'entrée NGINX dans un environnement cloud Kubernetes dynamique 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. Considérez ce scénario : vous travaillez pour un détaillant en ligne et avez besoin d’aide pour résoudre les problèmes de configuration de votre contrôleur Ingress open source. L’assistance commerciale n’est pas disponible, vous publiez donc le problème sur un forum comme Stack Overflow. Quelqu'un propose son aide et souhaite rechercher des problèmes dans les fichiers de configuration et de journal du contrôleur Ingress et d'autres composants Kubernetes. Ressentant la pression de devoir résoudre le problème rapidement, 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 continuellement vérifier les modifications apportées aux backends, ce qui consomme des ressources. Les demandes entrantes prennent plus de temps à traiter, ce qui entraîne le blocage de certaines demandes et augmente le risque d'expiration du délai d'attente. À mesure que vous évoluez vers davantage d'utilisateurs et de services, l'écart entre le nombre de requêtes entrantes par seconde et le nombre que Lua peut gérer s'élargit de manière exponentielle. La conséquence est une latence, une complexité et des coûts plus élevés.

  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 atteindre une efficacité maximale, les organisations adoptent la multi-location et adoptent un modèle Kubernetes qui prend en charge l’accès et l’isolement imposés par leurs processus métier tout en fournissant la cohérence et les contrôles dont leurs opérateurs ont besoin. Certains contrôleurs d'entrée peuvent vous aider à découper ces clusters grâce à un certain nombre de fonctionnalités et de concepts : entrées multiples, classes, espaces de noms et ressources limitées qui prennent en charge la définition 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.