Bonnes pratiques relatives à l'utilisation des passerelles de sortie Cloud Service Mesh sur les clusters GKE

Ce document explique comment utiliser les passerelles de sortie Cloud Service Mesh et d'autres contrôles Google Cloud pour sécuriser le trafic sortant des charges de travail déployées sur un cluster Google Kubernetes Engine (GKE). Ces contrôles peuvent limiter les connexions à des services externes basés sur l'identité de l'application source, l'espace de noms d'une équipe, le domaine de destination et d'autres propriétés des requêtes sortantes.

L'audience visée pour ce document inclut les ingénieurs réseau, de plate-forme et de sécurité qui administrent les clusters GKE utilisés par une ou plusieurs équipes de livraison de logiciels. Les contrôles décrits ici peuvent être particulièrement utiles pour les organisations qui doivent démontrer leur conformité avec les réglementations en vigueur (par exemple, le RGPD et le PCI).

Présentation

L'approche traditionnelle de la sécurité réseau est de définir des périmètres de sécurité autour d'un groupe d'applications. Les pare-feu sont utilisés dans ces périmètres pour autoriser ou refuser le trafic en fonction des adresses IP source et de destination, tout en faisant confiance aux applications et au trafic au sein même du périmètre. Toutefois, cette confiance implique des risques. Une personne interne malveillante ou une personne ayant compromis le périmètre peut évoluer librement au sein du réseau, accéder aux données exposés, accéder aux données externes, attaquer des systèmes tiers et interférer avec les systèmes d'administration.

Lorsque les charges de travail exécutées sur un cluster Kubernetes établissent des connexions de sortie vers des hôtes sur Internet, l'application de contrôles de sécurité traditionnels basés sur l'adresse IP peut s'avérer complexe du fait des raisons suivantes :

• Les adresses IP des pods ne représentent pas correctement l'identité de la charge de travail qui établit la connexion. Dans un environnement Kubernetes, les adresses IP des pods sont attribuées de manière éphémère et sont recyclées fréquemment au fur et à mesure que les pods démarrent ou s'arrêtent.

• Il est souvent impossible d'identifier un petit ensemble fixe d'adresses IP pour des hôtes de destination spécifiques. Les adresses IP changent fréquemment, varient selon les régions, et peuvent être extraites de grandes plages ou représenter des caches, des proxys ou des CDN.

• Plusieurs équipes partageant le même cluster mutualisé, avec une plage d'adresses IP sources partagées, peuvent avoir des exigences de connectivité externe différentes.

Cloud Service Mesh est un maillage de services entièrement géré sur Google Cloud, basé sur le maillage de services Open Source Istio. Un maillage de services offre une manière uniforme de connecter, de gérer et de sécuriser la communication des applications. Les maillages de services adoptent une approche centrée sur les applications et utilisent des identités d'application approuvées plutôt qu'une approche basée sur l'adresse IP du réseau.

Vous pouvez déployer un maillage de services de manière transparente, sans avoir à modifier le code d'application existant. L'utilisation d'un maillage de services permet de dissocier les responsabilités des administrateurs réseau du travail des équipes de développement chargées de livrer et de publier les fonctionnalités d'applications en offrant un contrôle déclaratif du comportement du réseau.

Cloud Service Mesh offre une option de déploiement de proxys autonomes,appelés passerelles de sortie, à la périphérie du maillage. Ce guide explique comment combiner les fonctionnalités du proxy de passerelle de sortie avec les fonctionnalités de Google Cloud pour contrôler, autoriser et observer le trafic sortant des charges de travail déployées sur un cluster GKE.

Architecture de défense en profondeur

Le diagramme ci-dessous montre une architecture qui adopte une approche de défense en profondeur pour un contrôle ultraprécis du trafic de sortie d'un cluster utilisé par plusieurs équipes. Les commandes réseau sont basées à la fois sur la couche 4 (transport) et la couche 7 (application).

L'architecture utilise les ressources et les contrôles suivants :

• Un cluster GKE privé : les nœuds d'un cluster GKE privé ne disposent que d'adresses IP internes et ne sont pas connectés par défaut à Internet.

• Cloud NAT : Cloud NAT autorise l'accès Internet sortant à partir du cluster privé.

• Règles de pare-feu de cloud privé virtuel (VPC) : configurez des règles de pare-feu VPC pour appliquer des contrôles de couche 4 (transport) à des connexions vers et depuis les nœuds du cluster GKE. Vous pouvez appliquer des règles de pare-feu VPC aux VM sur la base de comptes de service ou de tags réseau.

• Pools de nœuds GKE avec différents comptes de service : vous permet de configurer différentes règles de pare-feu à appliquer en fonction du pool de nœuds auquel appartient un nœud.

• Espaces de noms Kubernetes : vous créez des espaces de noms pour chaque équipe afin de les isoler et de fournir un contrôle administratif délégué. Les administrateurs réseau utilisent un espace de noms dédié pour déployer la passerelle de sortie et configurer le routage vers des hôtes externes.

• Règles de réseau Kubernetes : elles vous permettent d'appliquer des contrôles de couche 4 aux pods. Chaque règle de réseau est appliquée à un espace de noms et peut être appliquée de manière encore plus spécifique en ciblant certains pods d'un espace de noms.

• Passerelle de sortie : le trafic quittant des pods qui font partie du maillage est dirigé via des proxys de passerelle de sortie dédiés s'exécutant sur des nœuds dédiés. Déployez des passerelles de sortie avec un autoscaler horizontal de pods afin que le nombre d'instances dupliquées soit adapté en fonction du trafic.

• Règles d'autorisation : vous utilisez des règles d'autorisation de maillage pour appliquer des contrôles de couche 7 (application) au trafic entre les pods du maillage ainsi qu'au trafic quittant le maillage.

• Ressources sidecar : vous utilisez des ressources sidecar pour contrôler le champ d'application de la configuration des proxys side-car exécutés dans chaque pod de charge de travail. Vous pouvez utiliser la ressource sidecar pour configurer les espaces de noms, les pods et les services externes visibles par une charge de travail.

• Accès privé à Google : cette option permet aux nœuds et aux pods du cluster privé d'accéder aux API Google et d'extraire des images Docker à partir de Container Registry.

• GKE Workload Identity : avec Workload Identity, vous pouvez utiliser Identity and Access Management (IAM) pour accorder des autorisations d'API à des charges de travail spécifiques en appliquant le principe du moindre privilège, sans avoir à gérer les secrets.

Configurer les contrôles de sortie

Si vous utilisez la passerelle de sortie pour sécuriser le trafic sortant de votre maillage, nous vous recommandons de configurer les contrôles de défense en profondeur décrits dans la présente section.

Utiliser GKE en mode privé avec Cloud NAT

Lorsque la sécurité est importante, de nombreuses organisations ont pour première exigence de ne pas attribuer des adresses IP publiques à leurs charges de travail. Un cluster GKE privé répond à cette exigence. Vous pouvez configurer le mode VPC natif sur votre cluster privé afin que les pods et les services se voient attribuer des adresses IP provenant de plages secondaires du VPC. Les adresses IP des pods de VPC natif sont acheminées en mode natif au sein du réseau VPC.

Certaines charges de travail peuvent nécessiter un accès à des services en dehors du réseau VPC et à Internet. Pour permettre aux charges de travail de se connecter à des hôtes externes sans avoir besoin d'adresses IP publiques, configurez Cloud NAT pour fournir une traduction d'adresses réseau (NAT).

Assurez-vous que Cloud NAT est configuré de sorte que la passerelle de sortie puisse effectuer un nombre suffisant de connexions simultanées à des destinations externes. Vous pouvez éviter l'épuisement des ports et les problèmes liés aux délais de réutilisation des connexions en définissant le nombre minimal de ports par VM de manière appropriée. Pour en savoir plus, consultez la page Présentation de l'adresse et du port Cloud NAT. L'augmentation du nombre d'instances dupliquées de passerelle de sortie peut aider à réduire les risques de conflits de mappage indépendant du point de terminaison.

Configurer l'accès privé à Google pour les API et les services Google

Vos charges de travail nécessitent probablement l'accès aux API et services Google. Utilisez l'accès privé à Google avec des zones DNS personnalisées pour autoriser la connectivité des sous-réseaux VPC privés aux API Google à l'aide d'un ensemble de quatre adresses IP. Lorsque vous utilisez ces adresses IP, les pods n'ont pas besoin d'adresses IP externes et le trafic ne quitte jamais le réseau Google. Vous pouvez utiliser private.googleapis.com (199.36.153.8/30 ) ou restricted.googleapis.com (199.36.153.4/30), selon que vous utilisez ou non VPC Service Controls.

Utiliser Workload Identity et IAM pour sécuriser davantage les API et services Google

L'utilisation de Workload Identity est la méthode recommandée pour permettre aux charges de travail GKE de s'authentifier auprès des API Google et pour permettre aux administrateurs de contrôler les autorisations via IAM en appliquant le principe du moindre privilège.

Lorsque vous utilisez l'accès privé à Google, Workload Identity et IAM, vous pouvez autoriser les pods de charges de travail à contourner la passerelle de sortie et à se connecter directement aux API et services Google.

Utiliser les espaces de noms Kubernetes pour le contrôle administratif

Les espaces de noms sont une ressource organisationnelle utile dans les environnements qui comptent de nombreux utilisateurs, équipes ou locataires. Ils peuvent être considérés comme un cluster virtuel et permettent de déléguer la responsabilité administrative de groupes de ressources Kubernetes à différents administrateurs.

Les espaces de noms constituent une fonctionnalité importante pour l'isolation du contrôle administratif. Toutefois, ils ne fournissent pas par défaut d'isolation des nœuds, d'isolation du plan de données ou d'isolation du réseau.

Cloud Service Mesh s'appuie sur les espaces de noms Kubernetes en les utilisant comme unité de location dans un maillage de services. Les règles d'autorisation du maillage et les ressources sidecar peuvent restreindre la visibilité et l'accès en fonction des espaces de noms, de l'identité et des attributs de couche 7 (application) du trafic réseau.

De même, vous pouvez utiliser les règles de réseau Kubernetes pour autoriser ou refuser les connexions réseau au niveau de la couche 4 (transport).

Exécuter des passerelles de sortie sur des nœuds de passerelle dédiés

L'exécution de passerelles de sortie sur des nœuds dans un pool dédié de nœuds de passerelle présente plusieurs avantages. Les nœuds externes peuvent utiliser une configuration renforcée et vous pouvez configurer des règles de pare-feu VPC pour empêcher les charges de travail d'atteindre directement les hôtes externes. L'autoscaling des pools de nœuds peut être effectué indépendamment grâce à l'autoscaler de cluster.

Pour autoriser un contrôle administratif distinct de la passerelle de sortie, déployez-la dans un espace de noms istio-egress dédié. Toutefois, les espaces de noms sont une ressource à l'échelle du cluster et il n'est pas possible de les utiliser pour déterminer sur quels noeuds le déploiement doit s'exécuter. Pour le contrôle du déploiement, utilisez un sélecteur de nœuds pour le déploiement de la passerelle de sortie afin l'exécuter sur les nœuds étiquetés en tant que membres du pool de nœuds de passerelle.

Assurez-vous que seuls des pods de passerelle peuvent s'exécuter sur des nœuds de passerelle. Les autres pods doivent être rejetés par les nœuds de passerelle, sans quoi les contrôles de sortie pourraient être ignorés. Vous pouvez empêcher l'exécution de charges de travail sur certains nœuds en utilisant des rejets et tolérances. Vous devez rejeter les nœuds du pool de nœuds de passerelle et ajouter une tolérance correspondante au déploiement de la passerelle de sortie.

Appliquer des règles de pare-feu VPC à des nœuds spécifiques

Vous pouvez configurer le routage du maillage de services de manière à diriger le trafic sortant des charges de travail s'exécutant dans le pool de nœuds par défaut vers les passerelles de sortie exécutées dans le pool de nœuds de passerelle. Toutefois, la configuration de routage du maillage ne doit pas être considérée comme une limite de sécurité, notamment car une charge de travail peut contourner les proxys de maillage de différentes façons.

Pour empêcher les charges de travail d'application de se connecter directement aux hôtes externes, appliquez des règles de pare-feu de sortie restrictives aux nœuds du pool par défaut. Appliquez des règles de pare-feu distinctes aux nœuds de passerelle afin que les pods de passerelle de sortie s'exécutant sur ces nœuds puissent se connecter à des hôtes externes.

Lorsque vous créez une règle de pare-feu VPC, vous spécifiez les ports et les protocoles autorisés ou refusés par la règle de pare-feu ainsi que la direction du trafic auquel elle s'applique. Les règles de sortie s'appliquent au trafic sortant, tandis que les règles d'entrée s'appliquent au trafic entrant. La valeur par défaut est allow pour le trafic sortant et deny pour le trafic entrant.

Les règles de pare-feu sont appliquées dans l'ordre sur la base d'un numéro de priorité que vous pouvez spécifier. Les règles de pare-feu sont "avec état", ce qui signifie que si le trafic spécifique d'une VM est autorisé, le trafic renvoyé par la même connexion est également autorisé.

Le schéma suivant montre comment appliquer des règles de pare-feu distinctes aux nœuds de deux pools de nœuds différents en se basant sur le compte de service associé à un nœud. Dans ce cas, une règle de pare-feu deny all par défaut refuse l'accès en sortie pour l'ensemble du VPC. Pour éviter de remplacer les règles de pare-feu par défaut qui sont essentielles au bon fonctionnement de votre cluster, votre règle deny all doit utiliser une priorité plus faible, comme par exemple 65535. Une règle de pare-feu de sortie supplémentaire avec une priorité plus élevée sera appliquée aux nœuds de passerelle pour leur permettre de se connecter directement aux hôtes externes sur les ports 80 et 443. Le pool de nœuds par défaut n'a pas accès aux hôtes externes.

Utiliser les règles de réseau Kubernetes en tant que pare-feu pour les pods et les espaces de noms

Utilisez les règles de réseau Kubernetes pour appliquer une couche de sécurité supplémentaire dans le cadre d'une stratégie de défense en profondeur. Les règles de réseau s'appliquent aux espaces de noms et fonctionnent au niveau de la couche 4. Les règles de réseau vous permettent de limiter les entrées et sorties :

• Entre les espaces de noms
• Vers les pods d'un espace de noms
• Vers des ports et blocs d'adresses IP spécifiques

Dès lors qu'une règle de réseau sélectionne des pods dans un espace de noms, toutes les connexions qui ne sont pas explicitement autorisées sont rejetées. Lorsque plusieurs règles de réseau sont appliquées, le résultat est additif et représente une union des règles. L'ordre d'application des règles n'a pas d'importance.

Voici quelques exemples de règles réseau:

• Autoriser les connexions de sortie à partir des espaces de noms de la charge de travail vers les espaces de noms istio-system et istio-egress. Les pods doivent pouvoir se connecter au plan de contrôle et à la passerelle de sortie.
• Autoriser les charges de travail à effectuer des requêtes DNS à partir des espaces de noms de charge de travail et à destination du port 53 de l'espace de noms kube-system.
• Éventuellement, autoriser les charges de travail d'un même espace de noms à se connecter les unes aux autres.
• Éventuellement, autoriser les connexions de sortie entre les espaces de noms utilisés par différentes équipes de développement d'applications.
• Autoriser les connexions de sortie depuis les espaces de noms de charge de travail vers les adresses IP virtuelles des API Google (exposées via l'accès privé à Google). Cloud Service Mesh fournit une autorité de certification gérée et l'expose en tant qu'API, ce qui implique que les proxys side-car doivent pouvoir s'y connecter. Il est également possible que certaines charges de travail aient besoin d'accéder aux API Google.
• Autoriser les connexions de sortie à partir des espaces de noms de charge de travail et à destination du serveur de métadonnées GKE afin de permettre aux proxys sidecar et aux charges de travail d'effectuer des requêtes de métadonnées et de s'authentifier auprès des API Google.

Par défaut, lorsqu'un proxy sidecar est injecté dans un pod de charge de travail, les règles iptables sont programmées pour que le proxy capture tout le trafic TCP entrant et sortant. Toutefois, comme indiqué précédemment, les charges de travail peuvent contourner le proxy. Les règles de pare-feu VPC empêchent l'accès direct en sortie à partir des nœuds par défaut exécutant les charges de travail. Vous pouvez utiliser les règles de réseau Kubernetes pour vous assurer qu'une sortie externe directe est possible à partir des espaces de noms de la charge de travail et à destination de l'espace de noms istio-egress.

Si vous contrôlez également les entrées avec des règles de réseau, vous devez créer des règles d'entrée correspondant à vos règles de sortie.

Configuration et sécurité du service mesh

Les charges de travail exécutées dans un maillage de services ne sont pas identifiées en fonction de leurs adresses IP. Cloud Service Mesh attribue une identité forte et vérifiable sous la forme d'un certificat X.509 et d'une clé associée pour chaque charge de travail. La communication fiable entre les charges de travail est établie à l'aide de connexions TLS mutuel (mTLS) authentifiées et chiffrées.

L'utilisation de l'authentification mTLS avec une identité bien définie pour chaque application vous permet d'utiliser des règles d'autorisation de maillage afin de contrôler avec précision la manière dont les charges de travail peuvent communiquer avec des services externes.

Bien que le trafic puisse quitter le maillage directement à partir des proxys sidecar, si vous avez besoin d'un contrôle supplémentaire, nous vous recommandons d'acheminer le trafic via des passerelles de sortie comme décrit dans le présent guide.

Gérer la configuration des contrôles de sortie dans un espace de noms dédié

Autorisez les administrateurs réseau à gérer les contrôles de manière centralisée en utilisant un espace de noms istio-egress dédié pour la configuration du réseau maillé. Comme recommandé, vous allez déployer la passerelle de sortie sur l'espace de noms istio-egress. Vous pouvez créer et gérer des entrées de service, des passerelles et des règles d'autorisation dans cet espace de noms.

Exiger une configuration explicite des destinations externes

Assurez-vous que les proxys de maillage ne sont planifiés qu'avec des routes vers des hôtes externes qui sont explicitement définis dans le registre du maillage de services. Définissez le mode de règle de trafic sortant sur REGISTRY_ONLY dans une ressource sidecar par défaut pour chaque espace de noms. La définition d'une règle de trafic sortant pour le maillage ne doit pas, en soi, être considérée comme un contrôle de périmètre sécurisé.

Définir des destinations externes avec des entrées de services

Configurez des entrées de service pour enregistrer explicitement les hôtes externes dans le registre de services du maillage. Par défaut, les entrées de service sont visibles par tous les espaces de noms. Utilisez l'attribut exportTo pour contrôler les espaces de noms pour lesquels une entrée de service est visible. Les entrées de service déterminent les routes sortantes configurées dans les proxys de maillage, mais elles ne doivent pas être considérées comme un contrôle sécurisé pour déterminer à quelles charges de travail externes les hôtes peuvent se connecter.

Configurer le comportement de la passerelle de sortie avec la ressource de passerelle

Configurez le comportement d'équilibrage de charge des passerelles de sortie à l'aide de la ressource Gateway. L'équilibreur de charge peut être configuré pour un ensemble particulier d'hôtes, de protocoles et de ports, et associé à un déploiement de passerelle de sortie. Par exemple, une passerelle peut être configurée pour envoyer son trafic sortant vers les ports 80 et 443 pour tous les hôtes externes.

Dans Cloud Service Mesh, l'authentification mTLS automatique est activée par défaut. L'authentification mTLS automatique permet à un proxy sidecar client de détecter automatiquement si le serveur possède un sidecar. Le sidecar client envoie l'authentification mTLS aux charges de travail avec des sidecars et envoie du trafic en texte brut aux charges de travail sans side-car. Même avec l'authentification mTLS automatique, le trafic envoyé à la passerelle de sortie depuis des proxys sidecar n'utilise pas automatiquement l'authentification mTLS. Pour indiquer comment les connexions à la passerelle de sortie doivent être sécurisées, vous devez définir le mode TLS sur la ressource de passerelle. Dans la mesure du possible, utilisez l'authentification mTLS pour les connexions depuis des proxys sidecar vers la passerelle de sortie.

Il est possible d'autoriser les charges de travail à lancer elles-mêmes des connexions TLS (HTTPS). Si les charges de travail proviennent de connexions TLS, généralement sur le port 443, vous devez configurer la passerelle pour qu'elle utilise le mode passthrough pour les connexions sur ce port. Toutefois, l'utilisation du mode passthrough signifie que la passerelle ne peut pas appliquer de règles d'autorisation en fonction de l'identité de la charge de travail ou des propriétés de la requête chiffrée. De plus, à l'heure actuelle, il n'est pas possible d'utiliser conjointement les protocoles mTLS et passthrough.

Configurer des services virtuels et des règles de destination pour acheminer le trafic via la passerelle

Utilisez les services virtuels et les règles de destination pour configurer le routage du trafic des proxys sidecar vers les destinations externes en passant par la passerelle de sortie. Les services virtuels définissent des règles pour mettre en correspondance un certain trafic. Le trafic correspondant est ensuite envoyé à une destination. Les règles de destination peuvent définir des sous-ensembles (par exemple, la passerelle de sortie ou un hôte externe) et la manière dont le trafic doit être géré lorsqu'il est acheminé vers la destination.

Utilisez une seule règle de destination pour plusieurs hôtes de destination afin de spécifier explicitement la manière dont le trafic provenant des proxys side-car vers la passerelle doit être sécurisé. Comme indiqué précédemment, la méthode recommandée consiste à permettre aux charges de travail d'envoyer des requêtes en texte brut et à ce que le proxy side-car initie une connexion mTLS à la passerelle.

Utilisez une règle de destination pour chaque hôte externe afin de configurer la passerelle de sortie pour qu'elle "mette à niveau"' les requêtes HTTP pour qu'elles utilisent une connexion TLS (HTTPS) lors du transfert vers la destination. La mise à niveau d'une connexion en texte brut vers une connexion TLS est souvent appelée origine TLS.

Contrôler le champ d'application de la configuration du proxy avec la ressource sidecar

Configurez une ressource sidecar par défaut pour chaque espace de noms afin de contrôler le comportement des proxys sidecar. Utilisez la propriété de sortie de la ressource sidecar pour contrôler et minimiser les hôtes de destination configurés dans les écouteurs sortants des proxys. Une configuration minimale type peut inclure les destinations suivantes pour chaque espace de noms :

• Pods dans le même espace de noms
• API et services Google
• Serveur de métadonnées GKE
• Hôtes externes spécifiques configurés à l'aide d'entrées de service

La configuration des écouteurs sortants dans les proxys side-car ne doit pas être considérée comme un contrôle de sécurité.

Il est recommandé d'utiliser les ressources sidecar pour limiter la taille de la configuration du proxy. Par défaut, chaque proxy sidecar d'un maillage est configuré pour lui permettre d'envoyer du trafic vers tous les autres proxy. La consommation de mémoire des proxys sidecar et du plan de contrôle peut être considérablement réduite en limitant la configuration des proxys aux seuls hôtes avec lesquels ils doivent communiquer.

Utiliser la règle d'autorisation pour autoriser ou refuser le trafic sur la passerelle de sortie

AuthorizationPolicy est une ressource qui vous permet de configurer des règles de contrôle d'accès précises pour le trafic du réseau maillé. Vous pouvez créer des règles pour autoriser ou refuser le trafic en fonction des propriétés de la source, de la destination ou du trafic lui-même (par exemple, l'hôte ou les en-têtes d'une requête HTTP).

Pour autoriser ou refuser les connexions basées sur l'identité ou l'espace de noms de la charge de travail source, la connexion à la passerelle de sortie doit être authentifiée avec le protocole mTLS. Les connexions des side-cars vers la passerelle de sortie n'utilisent pas automatiquement le protocole mTLS. Par conséquent, la règle de destination pour les connexions à la passerelle doit explicitement spécifier le mode TLS ISTIO_MUTUAL.

Pour autoriser ou refuser les requêtes dans la passerelle à l'aide de règles d'autorisation, les charges de travail doivent envoyer des requêtes HTTP simples à des destinations extérieures au maillage. Les proxys sidecar peuvent ensuite transférer la requête à la passerelle à l'aide de mTLS. La passerelle peut alors établir une connexion TLS sécurisée à l'hôte externe.

Pour répondre aux exigences de sortie des différentes équipes et applications, configurez des règles d'autorisation de "moindre privilège" distinctes pour chaque espace de noms ou charge de travail. Par exemple, différentes règles peuvent être appliquées à la passerelle de sortie en spécifiant des règles basées sur l'espace de noms de la charge de travail source et sur les attributs de la requête, comme suit :

• Si l'espace de noms source est team-x ET que l'hôte de destination est example.com, autoriser le trafic.

  

• Si l'espace de noms source est team-y ET l'hôte de destination est httpbin.org ET le chemin d'accès est /status_418, autoriser le trafic.

  

Toutes les autres requêtes sont refusées.

Configurer la passerelle de sortie pour qu'elle initie des connexions TLS (HTTPS) vers la destination

Configurez des règles de destination pour que la passerelle de sortie initie des connexions TLS (HTTPS) vers des destinations externes.

Pour que l'initiation TLS au niveau de la passerelle de sortie fonctionne, les charges de travail doivent envoyer des requêtes HTTP simples. Si la charge de travail initie une connexion TLS, la passerelle de sortie encapsule le protocole TLS au-dessus du protocole TLS d'origine et les requêtes adressées au service externe échouent.

Étant donné que les charges de travail envoient des requêtes HTTP simples, configurez le proxy sidecar de la charge de travail pour établir une connexion mTLS lors de l'envoi des requêtes à la passerelle. La passerelle de sortie interrompt ensuite la connexion mTLS et établit une connexion TLS (HTTPS) standard avec l'hôte de destination.

Cette approche présente plusieurs avantages :

• Vous pouvez utiliser une règle d'autorisation pour autoriser ou refuser le trafic en fonction des attributs de la charge de travail source et des requêtes.

• Le trafic entre les pods de charge de travail et la passerelle de sortie est chiffré et authentifié (mTLS), et le trafic entre la passerelle de sortie et la destination est chiffré (TLS/HTTPS).

• À l'intérieur du maillage, les proxys sidecar peuvent observer et exploiter les propriétés des requêtes HTTP (par exemple, les en-têtes), ce qui offre des options supplémentaires d'observabilité et de contrôle.

• Le code de l'application peut être simplifié. Les développeurs n'ont pas besoin de gérer les certificats ou les bibliothèques clientes HTTPS, et le maillage de services peut garantir une communication sécurisée avec des algorithmes de chiffrement standards et à jour.

• Les connexions TLS provenant de services externes peuvent être réutilisées pour le trafic provenant de plusieurs pods. La réutilisation de la connexion est plus efficace et réduit le risque de dépassement des limites de connexion.

DNS, noms d'hôte et caractères génériques

Lors du routage, du refus ou de l'autorisation du trafic en fonction de l'hôte de destination, vous devez avoir totalement confiance dans l'intégrité de vos systèmes DNS pour résoudre les noms DNS vers l'adresse IP correcte. Sur les clusters Kubernetes Engine, le service DNS de Kubernetes gère les requêtes DNS et délègue les requêtes externes au serveur de métadonnées GKE ainsi qu'au DNS interne. Définissez l'attribut de résolution des entrées de service sur le DNS lors de l'acheminement vers des hôtes externes, afin que les proxys sidecar soient responsables des requêtes DNS.

Cloud Service Mesh peut acheminer le trafic en fonction d'hôtes génériques. Le cas le plus simple est un caractère générique pour les hôtes qui partagent un nom commun et sont hébergés sur un ensemble commun de serveurs. Par exemple, si un seul ensemble de serveurs peut diffuser les domaines correspondant à *.example.com, un hôte générique peut être utilisé.

Une passerelle de sortie standard ne peut pas être transférée sur la base d'hôtes génériques plus généraux et arbitraires (par exemple, *.com) en raison de certaines limites du proxy Envoy utilisé par Istio. Envoy ne peut acheminer le trafic que vers des hôtes prédéfinis, des adresses IP prédéfinies ou vers l'adresse IP de destination d'origine d'une requête. Lorsque vous utilisez une passerelle de sortie, l'adresse IP de destination d'origine de la requête est perdue car elle est remplacée par l'adresse IP de la passerelle, et les hôtes de destination arbitraires ne peuvent pas être préconfigurés.

Application administrative des règles

Utiliser le contrôle des accès basé sur les rôles Kubernetes (RBAC)

Seuls les administrateurs autorisés doivent pouvoir configurer les contrôles de sortie. Configurez le contrôle des accès basé sur les rôles Kubernetes (RBAC) pour éviter le contournement non autorisé des contrôles de sortie. Appliquez des rôles RBAC pour que seuls les administrateurs réseau puissent gérer les espaces de noms istio-egress, istio-system, et kube-system ainsi que les ressources suivantes :

• Sidecar
• ServiceEntry
• Gateway
• AuthorizationPolicy
• NetworkPolicy

Restreindre l'utilisation des tolérances

Comme décrit précédemment, vous pouvez utiliser des rejets et des tolérances pour éviter que les pods de charge de travail ne soient déployés sur des nœuds de passerelle. Toutefois, par défaut, rien n'empêche le déploiement des charges de travail avec une tolérance pour les nœuds de passerelle, ce qui permet de contourner les contrôles de sortie. S'il est possible de mettre en place un contrôle administratif centralisé sur les pipelines de déploiement, vous pouvez les utiliser pour appliquer des restrictions à l'utilisation de certaines clés de tolérance.

Une autre approche consiste à utiliser le contrôle d'admission Kubernetes. Anthos comprend un composant appelé Policy Controller qui agit en tant que contrôleur d'admission Kubernetes et vérifie que les déploiements répondent aux contraintes de stratégie que vous spécifiez.

Vérifier que le trafic est bien consigné dans des journaux

Il est souvent nécessaire de consigner tout le trafic qui traverse les périmètres réseau. La journalisation du trafic est essentielle si vous devez pouvoir démontrer la conformité avec les réglementations générales sur la protection des données. Les journaux de trafic sont envoyés directement à Cloud Logging et sont accessibles à partir des tableaux de bord Cloud Service Mesh dans la console Google Cloud. Vous pouvez filtrer les journaux en fonction de divers attributs, y compris la source/destination, l'identité, l'espace de noms, les attributs du trafic et la latence.

Pour faciliter le débogage avec kubectl, activez la journalisation du trafic sur stdout lors de l'installation de Cloud Service Mesh en utilisant le paramètre accessLogFile.

Des journaux d'audit sont envoyés à Cloud Logging chaque fois que l'autorité de certification Mesh crée un certificat pour une charge de travail.

Envisager l'utilisation d'un cluster distinct pour les passerelles de sortie dans des maillages multiclusters

Cloud Service Mesh peut être déployé sur plusieurs clusters GKE. Les réseaux maillés multicluster offrent de nouvelles possibilités pour contrôler le trafic de sortie et doivent respecter certaines limites.

Au lieu de déployer la passerelle de sortie sur un pool de nœuds dédié, vous pouvez la déployer sur un cluster distinct qui n'exécute pas de charges de travail standards. L'utilisation d'un cluster distinct offre une isolation semblable entre les charges de travail et les passerelles, tout en évitant les rejets et tolérances. La passerelle de sortie peut partager le cluster distinct avec des passerelles d'entrée ou d'autres services centraux.

Vous pouvez utiliser les règles de réseau Kubernetes dans des déploiements multiclusters. Cependant, comme elles fonctionnent au niveau de la couche 4 (transport), elles ne peuvent pas limiter les connexions entre clusters en se basant sur l'espace de noms ou sur le pod de destination.

Étape suivante

• Consultez le guide de renforcement de la sécurité dans GKE.
• Découvrez comment gérer la configuration et les règles de manière unifiée sur toute votre infrastructure avec Anthos Config Management.
• Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.