Activer la mutualisation et l’isolation des espaces de noms dans Kubernetes avec NGINX

Amir RawdatIngénieur solutions

[Note de la rédaction– Cet article est un extrait de notre livre numérique complet, « Gestion du trafic Kubernetes avec F5 NGINX : guide pratique ». Téléchargez-le gratuitement dès aujourd’hui].

À mesure que les organisations se développent, les workflows de développement et d’exploitation dans Kubernetes deviennent plus complexes. Il est généralement plus rentable — et potentiellement plus sûr — pour les équipes de partager les clusters et les ressources Kubernetes plutôt que de disposer chacune de leur propre cluster. Toutefois, vos déploiements peuvent subir de graves dommages si les équipes ne partagent pas ces ressources de manière sûre et sécurisée, ou si des pirates exploitent vos configurations.

Les pratiques de mutualisation et l’isolation des espaces de noms au niveau du réseau et des ressources permettent aux équipes de partager les ressources Kubernetes en toute sécurité. Vous pouvez également réduire considérablement l’ampleur des failles en isolant les applications pour chaque locataire. Cette méthode contribue à renforcer la résilience, car seules certaines parties des applications appartenant à des équipes spécifiques peuvent être compromises, tandis que les systèmes assurant d’autres fonctionnalités restent intacts.

NGINX Ingress Controller prend en charge plusieurs modèles de multitenance, mais nous observons deux approches principales. Le modèle du fournisseur de services d’infrastructure comprend généralement plusieurs déploiements de NGINX Ingress Controller avec une isolation physique, tandis que le modèle d’entreprise repose généralement sur un déploiement partagé de NGINX Ingress Controller avec une isolation par espace de noms. Dans cette section, nous examinons en détail le modèle d’entreprise. Pour en savoir plus sur l’exécution de plusieurs instances de NGINX Ingress Controller, consultez notre documentation.

Délégation avec NGINX Ingress Controller

NGINX Ingress Controller prend en charge à la fois la ressource Ingress standard de Kubernetes et les ressources Ingress personnalisées de NGINX, qui permettent une gestion plus sophistiquée du trafic ainsi que la délégation du contrôle de la configuration à plusieurs équipes. Les ressources personnalisées sont VirtualServer, VirtualServerRoute, GlobalConfiguration, TransportServer et Policy.

Avec NGINX Ingress Controller, les administrateurs de clusters utilisent les ressources VirtualServer pour configurer des règles de domaine Ingress (nom d’hôte) qui acheminent le trafic externe vers les applications back-end, et les ressources VirtualServerRoute pour déléguer la gestion d’URL spécifiques aux responsables d’applications et aux équipes DevOps.

Vous pouvez choisir entre deux modèles lors de la mise en œuvre de l’architecture mutualisée dans votre cluster Kubernetes : le libre-service complet et le libre-service restreint.

Mise en œuvre du libre-service complet

Dans un modèle entièrement en libre-service, les administrateurs n’interviennent pas dans les modifications quotidiennes de la configuration de NGINX Ingress Controller. Ils sont uniquement chargés de déployer NGINX Ingress Controller et le Service Kubernetes qui rend le déploiement accessible depuis l’extérieur. Les développeurs déploient ensuite des applications dans un espace de noms qui leur est attribué, sans faire appel à l’administrateur. Ils sont chargés de gérer les secrets TLS, de définir la configuration de l’équilibrage de charge pour les noms de domaine et de rendre leurs applications accessibles en créant des ressources VirtualServer ou Ingress standard.

Pour illustrer ce modèle, nous reproduisons l’application exemple bookinfo (créée à l’origine par Istio) avec deux sous-domaines, a.bookinfo.com et b.bookinfo.com, comme illustré dans le schéma suivant. Une fois que l’administrateur a installé et déployé NGINX Ingress Controller dans l’espace de noms nginx-ingress (surligné en vert), les équipes DevA (en rose) et DevB (en violet) créent leurs propres ressources VirtualServer et déploient des applications isolées dans leurs espaces de noms respectifs (A et B).

Les équipes DevA et DevB définissent des règles Ingress pour leurs domaines afin d’acheminer les connexions externes vers leurs applications.

L’équipe DevA applique l’objet de ressource VirtualServer suivant afin d’exposer les applications du domaine a.bookinfo.com dans l’espace de noms A.

Chargement de l’exemple de code…

De même, l’équipe DevB applique la ressource VirtualServer suivante afin d’exposer les applications du domaine b.bookinfo.com dans l’espace de noms B.

Chargement de l’exemple de code…

Mise en œuvre du libre-service restreint

Dans un modèle de libre-service restreint, les administrateurs configurent les ressources VirtualServer afin d’acheminer le trafic entrant dans le cluster vers l’espace de noms approprié, mais délèguent la configuration des applications dans les espaces de noms aux équipes de développement responsables. Chacune de ces équipes est uniquement responsable du sous-routage de son application tel qu’il est instancié dans la ressource VirtualServer et utilise des ressources VirtualServerRoute pour définir les règles de trafic et exposer les sous-routages d’application au sein de son espace de noms.

Comme illustré dans le schéma, l’administrateur du cluster installe et déploie NGINX Ingress Controller dans l’espace de noms « nginx-ingress » (surligné en vert), et définit une ressource VirtualServer qui établit des règles basées sur les chemins faisant référence aux définitions de ressources VirtualServerRoute.

Cette définition de ressource VirtualServer établit deux règles basées sur le chemin qui font référence à des définitions de ressources VirtualServerRoute pour deux sous-routes, /productpage-A et /productpage-B.

Chargement de l’exemple de code…

Les équipes de développement responsables des applications dans les espaces de noms « A » et « B » définissent ensuite des ressources VirtualServerRoute afin d’exposer les sous-routes des applications au sein de leurs espaces de noms. Les équipes sont isolées par espace de noms et ne peuvent déployer que les sous-routes d’applications définies par les ressources VirtualServer provisionnées par l’administrateur :

• L’équipe DevA (en rose dans le schéma) applique la ressource VirtualServerRoute suivante afin d’exposer la règle de sous-route d’application définie par l’administrateur pour « /productpage-A ».

  Chargement de l’exemple de code…

• L’équipe DevB (en violet) applique la ressource VirtualServerRoute suivante afin d’exposer la règle de sous-route de l’application définie par l’administrateur pour « /productpage-B ».

  Chargement de l’exemple de code…

Pour plus d’informations sur les fonctionnalités que vous pouvez configurer dans les ressources VirtualServer et VirtualServerRoute, consultez la documentation de NGINX Ingress Controller.

Remarque : Vous pouvez utiliser des types d’Ingress fusionnables pour configurer le routage entre espaces de noms, mais dans un modèle de délégation en libre-service restreint, cette approche présente trois inconvénients par rapport aux ressources VirtualServer et VirtualServerRoute :

1. Cette approche est moins sécurisée.
2. À mesure que votre déploiement Kubernetes s’agrandit et se complexifie, il devient de plus en plus sujet aux modifications accidentelles, car les types d’Ingress fusionnables n’empêchent pas les développeurs de définir des règles d’Ingress pour les noms d’hôte au sein de leur espace de noms.
3. Contrairement aux ressources VirtualServer et VirtualServerRoute, les types d’Ingress fusionnables ne permettent pas à la ressource Ingress principale (« master ») de contrôler les chemins des ressources Ingress secondaires (« minion »).

Exploiter le RBAC de Kubernetes dans un modèle de libre-service restreint

Vous pouvez utiliser le contrôle d’accès basé sur les rôles (RBAC) de Kubernetes pour réguler l’accès d’un utilisateur aux espaces de noms et aux ressources NGINX Ingress en fonction des rôles qui lui sont attribués.

Par exemple, dans un modèle de libre-service restreint, seuls les administrateurs disposant de privilèges spéciaux peuvent être autorisés en toute sécurité à accéder aux ressources VirtualServer, car celles-ci définissent le point d’entrée du cluster Kubernetes et toute utilisation abusive peut entraîner des interruptions à l’échelle du système.

Les développeurs utilisent les ressources VirtualServerRoute pour configurer les règles Ingress des routes d’application dont ils sont responsables. Les administrateurs définissent donc des politiques RBAC qui autorisent les développeurs à créer uniquement ces ressources. Ils peuvent même limiter cette autorisation à des espaces de noms spécifiques s’ils souhaitent contrôler encore davantage l’accès des développeurs.

Dans un modèle entièrement en libre-service, les développeurs peuvent se voir accorder en toute sécurité l’accès aux ressources VirtualServer, mais là encore, l’administrateur peut limiter cette autorisation à certains espaces de noms.

Pour plus d’informations sur l’autorisation RBAC, consultez la documentation Kubernetes.

Ajout de politiques

Les ressources Policy de NGINX constituent un autre outil permettant aux équipes distribuées de configurer Kubernetes dans des déploiements mutualisés. Elles offrent des fonctionnalités telles que l’authentification à l’aide d’OAuth et d’OpenID Connect (OIDC), la limitation du débit et le pare-feu d’application web (WAF). Pour être prises en compte dans la configuration Ingress, les ressources Policy doivent être référencées dans les ressources VirtualServer et VirtualServerRoute.

Par exemple, une équipe chargée de la gestion des identités dans un cluster peut définir des politiques de type « JSON Web Token » (JWT) ou OIDC, comme dans l’exemple suivant, qui utilise Okta comme fournisseur d’identité OIDC (IdP).

Chargement de l’exemple de code…

Les équipes NetOps et DevOps peuvent utiliser les ressources VirtualServer ou VirtualServerRoute pour référencer ces stratégies, comme dans cet exemple.

Chargement de l’exemple de code…

Ensemble, les ressources NGINX Policy, VirtualServer et VirtualServerRoute permettent de mettre en place des architectures de configuration distribuées, dans lesquelles les administrateurs peuvent facilement déléguer la configuration à d’autres équipes. Les équipes peuvent assembler des modules dans différents espaces de noms et configurer le contrôleur Ingress NGINX pour des cas d’utilisation avancés, de manière sécurisée, évolutive et facile à gérer.

Pour plus d’informations sur les ressources Policy, consultez la documentation de NGINX Ingress Controller.

Cet article est un extrait de notre livre numérique complet, « Gestion du trafic Kubernetes avec NGINX : guide pratique ». Téléchargez-le gratuitement dès aujourd’hui.

Essayez vous-même le contrôleur Ingress NGINX basé sur NGINX Plus grâce à un essai gratuit de 30 jours dès aujourd’hui, ou contactez-nous pour discuter de vos cas d’utilisation.

À propos de l’auteur

Amir RawdatIngénieur solutions

Autres articles de Amir Rawdat