Activation du multi-locataire et de l'isolement des espaces de noms dans Kubernetes avec NGINX

[ Editeur – Cet article est un extrait de notre eBook complet, Managing Kubernetes Traffic with F5 NGINX : Un guide pratique . [Téléchargez-le gratuitement dès aujourd'hui .]

À mesure que les organisations évoluent, les flux de travail de développement et d'exploitation dans Kubernetes deviennent plus complexes. Il est généralement plus rentable – et peut être plus sûr – pour les équipes de partager les clusters et les ressources Kubernetes, plutôt que de laisser chaque équipe disposer de son propre cluster. Mais vos déploiements peuvent subir des dommages critiques 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 multi-locataires et l’isolement de l’espace de noms au niveau du réseau et des ressources aident les équipes à partager les ressources Kubernetes en toute sécurité. Vous pouvez également réduire considérablement l’ampleur des violations en isolant les applications par locataire. Cette méthode permet de renforcer la résilience car seules les sous-sections d’applications appartenant à des équipes spécifiques peuvent être compromises, tandis que les systèmes fournissant d’autres fonctionnalités restent intacts.

NGINX Ingress Controller prend en charge plusieurs modèles multi-locataires, mais nous observons deux modèles principaux. Le modèle de fournisseur de services d’infrastructure inclut généralement plusieurs déploiements de contrôleur d’entrée NGINX avec isolation physique, tandis que le modèle d’entreprise utilise généralement un déploiement de contrôleur d’entrée NGINX partagé avec isolation de l’espace de noms. Dans cette section, nous explorons en profondeur le modèle d'entreprise ; pour plus d'informations sur l'exécution de plusieurs contrôleurs d'entrée NGINX, consultez notre documentation .

Délégation avec NGINX Ingress Controller

NGINX Ingress Controller prend en charge à la fois la ressource Kubernetes Ingress standard et les ressources NGINX Ingress personnalisées, qui permettent à la fois une gestion du trafic plus sophistiquée et 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 cluster utilisent les ressources VirtualServer pour provisionner les 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 propriétaires d'applications et aux équipes DevOps.

Vous pouvez choisir entre deux modèles lors de la mise en œuvre de la multilocation dans votre cluster Kubernetes : libre-service complet et libre-service restreint .

Mise en œuvre du libre-service complet

Dans un modèle de libre-service complet, les administrateurs ne sont pas impliqués dans les modifications quotidiennes apportées à la configuration du contrôleur d’entrée NGINX. Ils sont uniquement responsables du déploiement de NGINX Ingress Controller et du service Kubernetes qui expose le déploiement en externe. Les développeurs déploient ensuite des applications dans un espace de noms attribué sans impliquer l’administrateur. Les développeurs sont responsables de la gestion des secrets TLS, de la définition de la configuration d’équilibrage de charge pour les noms de domaine et de l’exposition de leurs applications en créant des ressources VirtualServer ou Ingress standard.

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

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

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

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

Mise en œuvre d'un libre-service restreint

Dans un modèle de libre-service restreint, les administrateurs configurent les ressources VirtualServer pour 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 responsable uniquement de son sous-itinéraire d’application tel qu’instancié dans la ressource VirtualServer et utilise les ressources VirtualServerRoute pour définir les règles de trafic et exposer les sous-itinéraires d’application dans son espace de noms.

Comme illustré dans le diagramme, 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 définit des règles basées sur le chemin faisant référence aux définitions de ressources VirtualServerRoute.

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

Les équipes de développeurs responsables des applications dans les espaces de noms A et B définissent ensuite les ressources VirtualServerRoute pour exposer les sous-routes d'application dans leurs espaces de noms. Les équipes sont isolées par espace de noms et limitées au déploiement de sous-routes d'application définies par les ressources VirtualServer provisionnées par l'administrateur :

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

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

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 .

Note: Vous pouvez utiliser des types d’entrée 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. C'est moins sécurisé.
2. À mesure que votre déploiement Kubernetes devient plus grand et plus complexe, il devient de plus en plus sujet à des modifications accidentelles, car les types d'entrée fusionnables n'empêchent pas les développeurs de définir des règles d'entrée pour les noms d'hôtes dans leur espace de noms.
3. Contrairement aux ressources VirtualServer et VirtualServerRoute, les types d’entrée fusionnables ne permettent pas à la ressource d’entrée principale (« maître ») de contrôler les chemins des ressources d’entrée « minion ».

Exploiter Kubernetes RBAC 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 attribués à l’utilisateur.

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

Les développeurs utilisent les ressources VirtualServerRoute pour configurer les règles d’entrée pour les itinéraires d’application qu’ils possèdent, afin que les administrateurs définissent des stratégies RBAC qui permettent aux développeurs de créer uniquement ces ressources. Ils peuvent même restreindre cette autorisation à des espaces de noms spécifiques s'ils ont besoin de réguler encore plus l'accès des développeurs.

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

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

Ajout de politiques

Les ressources de stratégie NGINX sont un autre outil permettant aux équipes distribuées de configurer Kubernetes dans des déploiements multilocataires. Les ressources de stratégie permettent 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). Les ressources de stratégie sont référencées dans les ressources VirtualServer et VirtualServerRoute pour prendre effet dans la configuration Ingress.

Par exemple, une équipe en charge de la gestion des identités dans un cluster peut définir des politiques JSON Web Token (JWT) ou OIDC comme celles-ci, qui utilisent Okta comme fournisseur d'identité OIDC (IdP).

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

Ensemble, les ressources NGINX Policy, VirtualServer et VirtualServerRoute permettent 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 d'entrée NGINX avec des cas d'utilisation sophistiqués de manière sécurisée, évolutive et gérable.

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

Cet article est un extrait de notre livre électronique complet, Gérer le trafic Kubernetes avec NGINX : Un guide pratique . Téléchargez-le gratuitement aujourd'hui .

Essayez dès aujourd'hui le contrôleur d'entrée NGINX basé sur NGINX Plus dans le cadre d'un essai gratuit de 30 jours ou contactez-nous pour discuter de vos cas d'utilisation .