Une gestion des configurations plus sûre avec NGINX Controller

Brian EhlertDirecteur de la gestion des produits

Au fil de nos échanges avec nos clients au cours de l’année écoulée, nous avons relevé quelques thèmes récurrents qui les incitent à évaluer des produits d’orchestration tels que « NGINX Controller » :

• Complexité – La gestion, la maintenance, la validation et l’application de vastes ensembles d’objets de configuration individuels provenant de différentes sources ne sont pas chose aisée.
• Fragilité – La montée en charge peut survenir rapidement, souvent en réponse à un événement. Elle est parfois stratégique, mais comme c’est souvent le cas dans les services d’exploitation, elle est imprévue et organique.
• Sécurité – Éviter les erreurs et détecter les problèmes avant la mise en production sont des principes fondamentaux de la méthodologie agile. Ils contribuent également à réduire la complexité et la fragilité.

Ce ne sont généralement pas des préoccupations auxquelles les clients sont confrontés lors du déploiement initial d’une application. Elles apparaissent plutôt au fil du temps, lorsque l’application rencontre le succès et doit monter en charge. Nous constatons que la montée en charge – ou, plus précisément, la montée en charge non planifiée – est la cause profonde commune des préoccupations énumérées ci-dessus.

Heureusement, le modèle d’objets de configuration de NGINX Controller répond à ces trois préoccupations :

• Il réduit la complexité du déploiement en regroupant en un seul endroit tous les composants de configuration susceptibles d’avoir une incidence sur un ensemble spécifique d’instances NGINX Plus.
• Elle réduit la fragilité en permettant aux équipes de valider et de tester les configurations avant leur mise en production, ce qui facilite la détection rapide des échecs et garantit la continuité du trafic utilisateur en production.
• Elle favorise la sécurité grâce à sa grande flexibilité. Au lieu de vous obliger à adapter vos processus au modèle, le modèle objet de configuration est conçu pour s’aligner sur vos processus métier et votre répartition des responsabilités : vous pouvez attribuer aux différentes unités opérationnelles la responsabilité des éléments de configuration qui leur reviennent.

Objets de configuration du contrôleur

Examinons plus en détail quelques objets de configuration clés afin de mieux comprendre le fonctionnement du modèle Controller.

Environnements

Dans la plupart des organisations, les logiciels passent par plusieurs étapes avant leur mise en production : développement, recette utilisateur, préproduction, production et autres étapes de contrôle qualité. Ces étapes correspondent à l’objet NGINX Controller appelé « environnement ».

Un environnement est une zone d’isolation pour les éléments de configuration au sein de Controller. C’est généralement à ce niveau que le contrôle d’accès basé sur les rôles (RBAC) est défini. Les environnements permettent de conserver des artefacts de configuration identiques au fil des différentes étapes, tout en apportant des modifications minimes à des éléments tels que les serveurs cibles, les centres de données et d’autres objets d’infrastructure qui diffèrent généralement d’un environnement à l’autre.

Passerelles

Une passerelle est un objet de configuration au sein d’un environnement, souvent utilisé comme niveau supérieur pour définir la manière dont les applications sont mises à la disposition des clients — avec des paramètres tels que le nom d’hôte, le protocole et le comportement TLS/SSL — bien que ces paramètres puissent également être définis à un niveau inférieur. En pratique, les objets Passerelle sont le plus souvent gérés par les équipes chargées des opérations réseau (NetOps), c’est-à-dire les personnes qui administrent les équipements réseau en périphérie ou la DMZ. Les passerelles utilisent également le concept de « placement », qui permet de relier Controller aux instances NGINX Plus qui reçoivent les configurations et effectuent le travail proprement dit.

Applications

Le niveau inférieur suivant correspond à l’objet de configuration App, dans lequel vous commencez à modéliser les applications et à regrouper les comportements de gestion du trafic. Vous pouvez utiliser autant ou aussi peu d’Apps que nécessaire pour répondre aux besoins de votre organisation. La seule exigence est qu’une App soit unique au sein d’un Environment.

Composants

Au sein d’une application, les composants décrivent le comportement souhaité en matière de gestion du trafic. Dans le cas le plus simple, tout le trafic correspondant à un chemin donné est envoyé vers le même groupe de serveurs. Toutefois, les composants permettent également de contrôler des mécanismes plus avancés, tels que la manipulation des en-têtes, la réécriture des URL, le comportement de l’équilibrage de charge côté backend, la gestion des cookies et d’autres paramètres. Le comportement relatif au nom d’hôte et à TLS/SSL peut également être défini à ce niveau.

Mettre le tout en cohérence

Voici une représentation visuelle de la relation entre les objets de configuration :

Notez que seuls deux groupes interagissent avec Controller : dans ce cas, deux équipes de développement, Referral et Transfers. En réalité, nous savons que le nombre de personnes impliquées dans la mise à disposition et la sécurité des applications est probablement bien plus élevé et englobe notamment les équipes réseau et sécurité (Platform Ops), DevOps et de développement d’applications. Les équipes disposant de la plus grande expertise peuvent définir des politiques et créer des workflows en libre-service conformes aux bonnes pratiques, tout en établissant des garde-fous pour les équipes qui travaillent avec les applications, les composants et les passerelles au sein de l’environnement « Dev », lequel couvre les centres de données Est et Ouest de l’organisation.

Examinons cela sous un angle légèrement différent, davantage du point de vue des métiers. Les responsables métier prennent de plus en plus souvent les décisions relatives aux applications modernes.

Le schéma suivant illustre un scénario plus proche de la réalité, avec un nombre bien plus important d’utilisateurs, notamment différentes équipes métier et Shawn, la personne chargée de gérer tous les renouvellements de certificats.

Nous avons désormais davantage d’acteurs individuels et de pipelines qui influent sur le flux de données qui en résulte.

À mesure que chaque pipeline progresse à travers les différentes modifications d’objets, depuis le système de gestion de versions (tel que GitHub) jusqu’à Controller, les objets de configuration sont validés côté Controller, puis combinés avec les éventuels objets associés avant que les modifications ne soient transmises aux instances NGINX Plus.

C’est ainsi que Controller peut contribuer à sécuriser davantage la gestion des configurations : en s’assurant que les dernières modifications sont compatibles avec les paramètres précédents et ceux définis par les autres responsables d’applications et de secteurs d’activité.

Nous sommes conscients qu’en pratique, toutes les configurations appliquées à une même instance NGINX Plus doivent pouvoir coexister, sans toutefois entrer en conflit, se chevaucher ou être incompatibles. Il est également important de détecter les conflits en amont et d’en informer les personnes chargées de fournir la configuration de chaque composant.

Dans l’exemple ci-dessus, lorsque le composant Referral tente d’utiliser le même motif d’expression régulière que celui déjà mis en œuvre par le composant Transfers, un conflit de chemins est immédiatement détecté, et l’équipe Referral peut être avertie bien avant qu’elle ne tente de déployer cette configuration en production – évitant ainsi les nombreux problèmes liés à une mauvaise configuration.

En ce qui concerne les certificats, Shawn est habilité, grâce à la fonctionnalité RBAC de Controller, à appliquer immédiatement les modifications apportées aux certificats. Les responsables de la maintenance de la Gateway et des Components doivent simplement référencer les certificats appropriés, et Shawn peut gérer leur cycle de vie en toute confiance. Si Shawn met à jour un certificat dans Controller, celui-ci est déployé sur les instances appropriées, sans avoir à gérer dans l’urgence l’expiration d’un certificat.

Maintenant que NGINX Controller dispose de tous vos objets de configuration et d’une association de placement avec une ou plusieurs instances NGINX Plus, il peut effectuer les dernières étapes : appliquer la configuration.

La sécurité en pratique

En définitive, l’objectif de la gestion des configurations avec Controller est d’appliquer la bonne configuration aux bonnes instances NGINX Plus, au bon emplacement. S’assurer que les applications, les composants, les passerelles, ainsi que l’ensemble des certificats et instances associés sont correctement configurés permet de réaliser des déploiements plus sûrs et plus évolutifs.

Cette vérification finale constitue la dernière étape du processus de gestion de la configuration, que Controller rend plus simple et plus sûr. L’ensemble de la configuration est vérifié lors de son application à une instance NGINX Plus pour laquelle un objet associé a été modifié – par exemple, la persistance de session dans un groupe de charges de travail web pour NGINX Plus déployé en tant que proxy – afin de s’assurer que l’instance est compatible avec la configuration souhaitée. Si cette condition est remplie, la configuration est appliquée. Enfin, par mesure de sécurité supplémentaire, si une erreur survient lors de l’application de la configuration, Controller rétablit une configuration antérieure.

En plus de s’assurer que les configurations sont conformes, Controller peut également tirer parti des fonctionnalités avancées de NGINX, telles que le drainage des sessions, lors de l’application d’une nouvelle configuration, garantissant ainsi que les sites restent disponibles et performants pendant les changements.

Pour les équipes d’exploitation, les concepts et les modèles de workflow présentés ci-dessus contribuent à la sécurité qu’offre NGINX Controller en matière de gestion des configurations. Ces mesures de protection permettent d’harmoniser les workflows et les différentes équipes qui travaillent sur des applications modernes, tout en répondant aux besoins de l’entreprise.

Pour essayer NGINX Controller, commencez votre essai gratuit de 30 jours dès aujourd’hui ou contactez-nous pour discuter de vos cas d’utilisation.

À propos de l’auteur

Brian EhlertDirecteur de la gestion des produits

Autres articles de Brian Ehlert