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 vous faites grandir votre organisation, les flux de travail de développement et d’exploitation sous Kubernetes deviennent plus complexes. Il est souvent plus rentable et plus sûr que vos équipes partagent les clusters et ressources Kubernetes plutôt que d’attribuer un cluster à chaque équipe. Mais vos déploiements risquent de subir de graves dommages si vos équipes ne partagent pas ces ressources de façon sûre ou si des pirates exploitent vos configurations.

Les pratiques de multi‑tenant et l’isolation des espaces de noms au niveau du réseau et des ressources permettent à vos équipes de partager les ressources Kubernetes en toute sécurité. Vous limitez aussi considérablement l’impact des violations en isolant les applications par locataire. Cette approche renforce la résilience, car seules des parties spécifiques des applications gérées par certaines équipes peuvent être compromises, tandis que les systèmes offrant d’autres fonctions restent protégés.

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 gère à la fois la ressource Kubernetes Ingress standard et les ressources NGINX Ingress personnalisées, qui vous offrent une gestion du trafic plus avancée ainsi qu’une 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, vous utilisez les ressources VirtualServer pour configurer des règles de domaine Ingress (nom d’hôte) qui orientent le trafic externe vers les applications back-end, et les ressources VirtualServerRoute pour confier la gestion d’URL spécifiques aux propriétaires d’application 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, vous ne gérez pas les modifications quotidiennes de la configuration du contrôleur NGINX Ingress. Vous vous chargez uniquement du déploiement du contrôleur NGINX Ingress et du Service Kubernetes qui expose ce déploiement à l’extérieur. Les développeurs déploient ensuite les applications dans un espace de noms dédié, sans votre intervention. Ils gèrent les secrets TLS, configurent l’équilibrage de charge pour les noms de domaine, et exposent leurs applications en créant des ressources VirtualServer ou Ingress standard.

Pour illustrer ce modèle, nous reproduisons l’application exemple bookinfo (créée initialement par Istio) avec deux sous-domaines, a.bookinfo.com et b.bookinfo.com, comme le montre le schéma ci-dessous. Lorsque l’administrateur installe et déploie NGINX Ingress Controller dans l’espace de noms nginx-ingress (en vert), les équipes DevA (en rose) et DevB (en violet) créent leurs propres ressources VirtualServer et déploient leurs applications de manière isolée 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 la même manière, l’équipe DevB déploie 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, vous configurez les ressources VirtualServer pour diriger le trafic entrant dans le cluster vers l’espace de noms adéquat, tout en laissant les équipes de développement gérer la configuration des applications dans ces espaces. Chaque équipe gère uniquement sa sous-route d’application définie dans la ressource VirtualServer et utilise les ressources VirtualServerRoute pour établir les règles de trafic et exposer ses sous-routes d’application dans son espace de noms.

Comme le montre le schéma, l’administrateur du cluster installe et déploie le contrôleur NGINX Ingress dans l’espace de noms nginx-ingress (en vert), et crée une ressource VirtualServer avec des règles basées sur le chemin qui renvoient aux définitions des ressources VirtualServerRoute.

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

Les équipes de développeurs en charge des applications dans les namespaces A et B définissent ensuite les ressources VirtualServerRoute pour exposer les sous-routes des applications au sein de leurs namespaces. Ces équipes restent isolées par namespace et ne peuvent déployer que les sous-routes d’applications définies par les ressources VirtualServer fournies par l’administrateur :

• L’équipe DevA (en rose dans le schéma) applique la ressource VirtualServerRoute suivante pour exposer la règle de sous-route de l’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 de l’application définie par l’administrateur pour /productpage-B.

Pour en savoir plus sur les fonctionnalités configurables dans les ressources VirtualServer et VirtualServerRoute, consultez la documentation du contrôleur d’entrée NGINX.

Note : Vous pouvez utiliser des types d'Ingress fusionnables pour configurer le routage inter-namespaces, mais dans un modèle de délégation en libre-service restreint, cette méthode 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’Ingress fusionnables ne donnent pas à la ressource Ingress principale (« maître ») le contrôle des chemins des ressources Ingress « subordonnées ».

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 gérer l’accès des utilisateurs aux espaces de noms et aux ressources NGINX Ingress selon les rôles qui leur sont attribués.

Par exemple, dans un modèle de libre-service restreint, nous autorisons uniquement les administrateurs ayant des privilèges spéciaux à accéder en toute sécurité aux ressources VirtualServer – car ces ressources déterminent le point d’entrée du cluster Kubernetes, une mauvaise utilisation peut provoquer des interruptions du système entier.

Vous utilisez les ressources VirtualServerRoute pour définir les règles d’Ingress des routes applicatives dont vous êtes responsable, tandis que les administrateurs créent des politiques RBAC qui vous permettent uniquement de créer ces ressources. Ils peuvent aussi limiter cette autorisation à des espaces de noms précis pour mieux cadrer votre accès.

Dans un modèle de libre-service complet, vous pouvez accorder aux développeurs un accès sécurisé aux ressources VirtualServer, tout en limitant ce droit aux namespaces spécifiques selon vos règles d'administration.

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

Ajout de politiques

Les ressources de politique NGINX offrent un outil supplémentaire pour permettre aux équipes réparties de configurer Kubernetes dans des environnements à locataires multiples. Les ressources de politique activent des fonctionnalités telles que l'authentification avec OAuth et OpenID Connect (OIDC), la limitation de débit et le pare-feu applicatif web (WAF). Nous référons les ressources de politique dans les ressources VirtualServer et VirtualServerRoute pour qu’elles soient appliquées 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 utilisent les ressources VirtualServer ou VirtualServerRoute pour référencer ces politiques, comme montré dans cet exemple.

Les ressources NGINX Policy, VirtualServer et VirtualServerRoute vous offrent une architecture de configuration distribuée qui facilite la délégation aux autres équipes. Vous assemblez des modules entre espaces de noms et configurez le contrôleur d'entrée NGINX pour des cas d’usage complexes, en toute sécurité, scalabilité et simplicité de gestion.

Pour en savoir plus sur les ressources de politique, consultez la documentation du contrôleur d'entrée NGINX.

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 .