Guide pour choisir un contrôleur Ingress, 2e partie : risques et pérennisation

Jenn GileResponsable du marketing produit, NGINX

Éditeur – Cet article fait partie d’une série en 10 volets :

1. Réduisez la complexité grâce à Kubernetes prêt pour la production
2. Comment améliorer la résilience dans Kubernetes grâce à une 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 Ingress, 1re partie : identifiez vos besoins
6. Guide pour choisir un contrôleur Ingress, 2e partie : risques et pérennisation (cet article)
7. Guide pour choisir un contrôleur Ingress, 3e partie : open source, par défaut ou commercial
8. Guide pour choisir un contrôleur Ingress, 4e partie : les différentes options de contrôleur Ingress NGINX
9. Comment choisir un maillage de services
10. Tests de performance des contrôleurs Ingress NGINX dans un environnement cloud Kubernetes dynamique

Vous pouvez également télécharger l’ensemble des articles sous forme d’e-book gratuit : « Faire passer Kubernetes des tests à la production ».

Dans la première partie de notre guide sur le choix d’un contrôleur Ingress, nous avons expliqué comment définir vos besoins. Mais il n’est toujours pas temps de tester les produits ! Dans cet article, nous expliquons comment un contrôleur Ingress inadapté peut ralentir le rythme de vos mises en production et même vous faire perdre des clients. Comme tout outil, les contrôleurs Ingress peuvent présenter des risques et compromettre l’évolutivité future. Voyons comment écarter les options susceptibles de faire plus de mal que de bien.

Risques liés aux contrôleurs Ingress

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ématiques sont souvent étroitement liées : lorsque l’une se manifeste, les autres sont susceptibles d’apparaître également. Chacun de ces risques peut être introduit par un contrôleur Ingress, et il appartient à votre organisation de déterminer s’il est acceptable. Les consommateurs d’aujourd’hui sont volatils, et tout ce qui nuit à leur expérience numérique peut être jugé inacceptable, malgré un ensemble de fonctionnalités attrayant.

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 d’une architecture de microservices : légers et de conception simple. Il est possible de développer un contrôleur Ingress très riche en fonctionnalités tout en respectant ces principes, mais ce n’est pas toujours le cas. Certains concepteurs intègrent trop de fonctions ou recourent à des scripts alambiqués pour ajouter des capacités qui ne sont pas natives du moteur sous-jacent, ce qui rend le contrôleur Ingress inutilement complexe.

Et pourquoi est-ce important ? Dans Kubernetes, un outil trop complexe peut nuire aux performances des applications et limiter votre capacité à faire évoluer horizontalement votre déploiement. La taille d’un contrôleur Ingress permet généralement de repérer une complexité excessive : plus son empreinte est importante, plus l’outil est complexe.

Latence : le contrôleur Ingress ralentit-il vos applications ?

Les contrôleurs Ingress peuvent augmenter la latence en raison de l’utilisation des ressources, d’erreurs et de délais d’expiration. Examinez la latence ajoutée dans les déploiements statiques et dynamiques, puis écartez les options qui entraînent une latence inacceptable au regard de vos exigences internes. Pour en savoir plus sur l’impact des reconfigurations sur la vitesse des applications, consultez l’article « Tests de performances des contrôleurs Ingress NGINX dans un environnement cloud Kubernetes dynamique » sur notre blog.

Sécurité : le contrôleur Ingress ouvre-t-il la porte aux pirates informatiques ?

Les vulnérabilités et expositions courantes (CVE) sont omniprésentes sur Internet aujourd’hui, et le délai nécessaire à votre fournisseur de contrôleur Ingress pour fournir un correctif de CVE peut faire toute la différence entre la sécurité et une compromission. Selon la tolérance au risque de votre organisation, vous pouvez écarter les solutions qui mettent plus de quelques jours (ou, tout au plus, quelques semaines) à fournir des correctifs.

Au-delà des CVE, certains contrôleurs Ingress vous exposent à une autre vulnérabilité potentielle. Imaginez le scénario suivant : vous travaillez pour un commerçant en ligne et avez besoin d’aide pour résoudre un problème de configuration de votre contrôleur Ingress open source. Aucune assistance commerciale n’étant disponible, vous publiez votre problème sur un forum tel que Stack Overflow. Quelqu’un vous propose son aide et souhaite rechercher d’éventuels problèmes dans les fichiers de configuration et les journaux du contrôleur Ingress et d’autres composants Kubernetes. Pressé de résoudre 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 de sécurité : des numéros de carte bancaire ont été dérobés dans les dossiers de vos clients. Oups. Il s’avère que les fichiers que vous avez partagés contenaient des informations qui ont servi à infiltrer votre application. Ce scénario illustre l’une des principales raisons pour lesquelles les entreprises choisissent de payer pour bénéficier d’une assistance : la garantie de confidentialité.

Remarque sur les contrôleurs Ingress 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 afin d’étendre les fonctionnalités de NGINX Open Source. Il existe par ailleurs plusieurs contrôleurs Ingress basés sur OpenResty qui, selon nous, pourraient présenter deux risques supplémentaires par rapport à nos contrôleurs Ingress basés sur NGINX Open Source et NGINX Plus :

• Délais d’expiration – Comme indiqué, OpenResty utilise des scripts Lua pour mettre en œuvre des fonctionnalités avancées telles que celles de notre contrôleur Ingress commercial basé sur NGINX Plus. L’une de ces fonctionnalités est la reconfiguration dynamique, qui permet de s’affranchir d’une exigence de NGINX Open Source réduisant la disponibilité : le rechargement obligatoire de la configuration NGINX lorsque les points de terminaison des services changent. Pour effectuer une reconfiguration dynamique avec OpenResty, le gestionnaire Lua choisit le service en amont vers lequel acheminer la requête, ce qui évite d’avoir à recharger la configuration NGINX. Cependant, Lua doit vérifier en permanence si les backends ont changé, ce qui consomme des ressources. Le traitement des requêtes entrantes prend plus de temps, ce qui bloque certaines d’entre elles et augmente le risque d’expiration. À mesure que le nombre d’utilisateurs et de services augmente, l’écart entre le nombre de requêtes entrantes par seconde et le nombre de requêtes que Lua peut traiter se creuse de manière exponentielle. Il en résulte une latence, une complexité et des coûts accrus. Consultez Tests de performances des contrôleurs Ingress NGINX dans un environnement cloud Kubernetes dynamique pour découvrir l’ampleur de la latence que Lua peut ajouter.
• Retards dans la publication des correctifs de CVE – Par rapport aux contrôleurs Ingress de NGINX, les correctifs de CVE mettent inévitablement plus de temps à être intégrés aux contrôleurs Ingress reposant sur des outils tels qu’OpenResty, eux-mêmes basés sur NGINX Open Source. Comme nous l’expliquons en détail dans Atténuer rapidement et facilement les vulnérabilités de sécurité avec NGINX Plus, lorsqu’une CVE affectant NGINX est découverte, nous en sommes généralement informés en tant qu’éditeur avant sa divulgation publique. Cela nous permet de publier un correctif pour NGINX Open Source et NGINX Plus dès l’annonce de la CVE. Les technologies basées sur NGINX Open Source peuvent ne prendre connaissance de la CVE qu’à ce moment-là et, d’après notre expérience, les correctifs d’OpenResty accusent un retard considérable sur les nôtres – quatre mois dans un cas récent. La publication de correctifs pour un contrôleur Ingress basé sur OpenResty prend inévitablement encore plus de temps, ce qui laisse à un acteur malveillant de nombreuses occasions d’exploiter la vulnérabilité.

Préparez votre contrôleur Ingress pour l’avenir

Même si vous commencez tout juste à vous familiariser avec Kubernetes, il y a de fortes chances que vous envisagiez un jour de le déployer en production. Au fil du temps, vos besoins sont susceptibles d’augmenter dans quatre domaines principaux : l’infrastructure, la sécurité, l’assistance et la mutualisation.

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

Il est rare qu’une organisation s’engage pleinement et durablement en faveur d’un seul type d’environnement. Le plus souvent, les organisations combinent des environnements sur site et dans le cloud, qui peuvent inclure des clouds privés, publics, hybrides et multiclouds. (Pour mieux comprendre les différences entre ces environnements, consultez l’article « Quelle est la différence entre le multicloud et le cloud hybride ? ».)

Comme nous l’avons mentionné dans la première partie de cette série, il peut être tentant de choisir les outils fournis par défaut avec chaque environnement, mais les contrôleurs Ingress par défaut présentent de nombreux problèmes spécifiques. Nous aborderons tous leurs inconvénients dans la troisième partie de cette série, mais le problème le plus important pour garantir la pérennité de votre infrastructure est la dépendance vis-à-vis d’un fournisseur : vous ne pouvez pas utiliser un contrôleur Ingress propre à un cloud dans tous vos environnements. L’utilisation d’outils propres à un cloud et fournis par défaut limite votre capacité à évoluer, car elle ne vous laisse que deux options peu attrayantes :

1. Essayer d’adapter le cloud existant à tous vos besoins
2. Réécrivez toutes vos configurations – non seulement celles de l’équilibrage de charge, mais aussi celles de la sécurité ! – pour le contrôleur Ingress dans chaque nouvel environnement

Si la première option n’est souvent pas viable pour des raisons commerciales, la deuxième est également délicate, car elle entraîne une prolifération des outils, crée de nouvelles vulnérabilités de sécurité et impose à vos collaborateurs des courbes d’apprentissage abruptes. La troisième option, qui est aussi la plus efficace, consiste à choisir dès le départ un contrôleur Ingress indépendant de l’infrastructure, afin de pouvoir utiliser le même outil dans tous vos environnements.

En matière d’infrastructure, il faut tenir compte d’un autre élément : les certifications. Prenons l’exemple de Red Hat OpenShift Container Platform (OCP). Si vous utilisez OCP, vous savez probablement déjà que Red Hat Marketplace propose des opérateurs certifiés pour OCP, notamment NGINX Ingress Operator. Les normes de certification de Red Hat vous offrent la tranquillité d’esprit de savoir que l’outil fonctionne avec votre déploiement et peut même bénéficier d’un support conjoint de Red Hat et du fournisseur. De nombreuses organisations exigent l’utilisation d’outils certifiés pour des raisons de sécurité et de stabilité. Ainsi, même si vous n’en êtes actuellement qu’à la phase de test, il est judicieux de garder à l’esprit les exigences de votre entreprise concernant les environnements de production.

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

L’époque où la seule sécurité périmétrique suffisait à protéger les applications et les clients est révolue. Les applications Kubernetes sont mieux protégées lorsque les mécanismes de sécurité, notamment l’authentification et l’autorisation, sont déployés au plus près 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 « zéro confiance » au sein de Kubernetes, vous pourriez bientôt avoir besoin d’un maillage de services.

Quel est le rapport entre tout cela et votre contrôleur Ingress ? Il est considérable ! Centraliser la sécurité (authentification, autorisation, protection contre les attaques par déni de service, pare-feu d’applications web) au niveau du point d’entrée Ingress est tout à fait pertinent, tant en matière de coûts que d’efficacité. Et si la plupart des maillages de services peuvent être intégrés à la plupart des contrôleurs Ingress, la manière dont cette intégration est réalisée est déterminante. Un contrôleur Ingress en adéquation avec votre stratégie de sécurité peut vous éviter bien des difficultés tout au long du développement de vos applications.

Consultez « Sécuriser les applications cloud natives sans perdre en rapidité » pour en savoir plus sur les risques liés à la mise à disposition d’applications cloud natives, ainsi que « Déploiement de services applicatifs dans Kubernetes, 2e partie » pour mieux comprendre les facteurs qui déterminent l’emplacement optimal des outils de sécurité.

Support : jusqu’où pouvez-vous vous permettre de vous débrouiller seul ?

Lorsque les équipes commencent tout juste à expérimenter avec Kubernetes, le support, qu’il soit assuré par la communauté ou par une entreprise, n’est souvent pas la priorité absolue. Cela ne pose pas de problème si vos équipes disposent de beaucoup de temps pour élaborer leurs propres solutions et solutions de contournement, mais cette approche n’est pas viable lors du passage en production. Même si vous n’avez pas besoin de support aujourd’hui, il peut être judicieux de choisir un contrôleur Ingress qui vous permettra d’en ajouter à l’avenir, ou qui propose une formule de support abordable pouvant évoluer à mesure que vous montez en charge.

Multilocation – Comment plusieurs équipes et applications peuvent-elles partager un environnement de conteneurs 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 commencent toutes les histoires ? Souvent, la suite raconte comment cette équipe développe avec succès son application Kubernetes, ce qui conduit 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 mutualisation et un modèle Kubernetes qui prend en charge les accès et l’isolation imposés par leurs processus métier, tout en offrant à leurs opérateurs la maîtrise et les mécanismes de contrôle dont ils ont besoin. Certains contrôleurs Ingress peuvent vous aider à segmenter ces clusters grâce à diverses fonctionnalités et notions : plusieurs ressources Ingress, des classes, des espaces de noms et des ressources à portée limitée permettant de configurer des contrôles d’accès basés sur les rôles (RBAC).

Étape suivante : affiner la sélection

Maintenant que vous avez réfléchi à vos besoins, à votre tolérance au risque et à la pérennité de votre solution, vous disposez de suffisamment d’informations pour commencer à faire le tri parmi le très large éventail de contrôleurs Ingress. En les regroupant par catégorie, vous pourrez franchir rapidement cette étape. Dans la troisième partie de notre série, nous examinerons trois catégories de contrôleurs Ingress, ainsi que les avantages et les inconvénients de chacune.

À propos de l’auteur

Jenn GileResponsable du marketing produit, NGINX

Autres articles de Jenn Gile