Cas d'utilisation sur la sécurité des services

Ce document décrit les cas d'utilisation courants de la sécurité Cloud Service Mesh. Ces informations peuvent vous aider à déterminer le modèle de sécurité qui répond le mieux à vos besoins. Ce document fournit également une vue d'ensemble de ce que vous devez configurer pour chaque cas d'utilisation.

Pour en savoir plus sur la sécurité des services, consultez la page Sécurité des services Cloud Service Mesh.

Activer TLS pour les services du réseau maillé

Dans un maillage de services, vous pouvez activer le protocole TLS mutuel (mTLS) afin que le client et le serveur utilisés dans une communication doivent valider leurs identités et chiffrer les communications.

Authentification mutuelle TLS (mTLS) dans un maillage de services (cliquez pour agrandir)

La section suivante omet les discussions sur Mesh, Gateway et Route. ressources. Ces ressources d'API sont nécessaires pour créer votre maillage et votre route mais vous n'avez pas besoin de les mettre à jour pour activer mTLS.

Le modèle précédent peut être obtenu en configurant les ressources d'API Compute Engine suivantes. Ce schéma utilise des proxys side-car, mais la configuration d'une application gRPC sans proxy avec mTLS utilise les mêmes ressources.

Ressources de l'API Compute Engine pour l'authentification mTLS au sein d'un réseau maillé (cliquez pour agrandir)

Pour créer ce modèle, procédez comme suit :

1. Créez une règle TLS (Transport Layer Security) cliente.
2. Créez une règle TLS de serveur.
3. Mettez à jour le champ securitySettings dans vos services de backend globaux existants pour référencer la nouvelle règle TLS du client.

4. Créez une règle de point de terminaison :

   1. Référencez la règle TLS du serveur dans le champ server_tls_policy.

   2. Définissez EndpointMatcher pour sélectionner les clients Cloud Service Mesh qui doivent appliquer l'authentification sur le trafic entrant.

      La sélection des clients Cloud Service Mesh est basée sur les étiquettes spécifiées dans la configuration d'amorçage du client Cloud Service Mesh. Ces libellés peuvent être fournis manuellement ou automatiquement en fonction des libellés fournis à vos déploiements Google Kubernetes Engine (GKE).

      Dans le schéma précédent, les étiquettes "mesh-service":"true" sont configurés sur la règle de point de terminaison et sur les clients Cloud Service Mesh. Vous pouvez choisir des libellés adaptés à votre déploiement.

   3. Vous pouvez également définir un TrafficPortSelector qui applique les stratégies uniquement lorsque des requêtes entrantes sont envoyées au port spécifié sur l'entité de plan de données.

Le schéma suivant présente les ressources Compute Engine que vous configurez pour mTLS, que vous utilisiez Envoy ou une application gRPC sans proxy.

Ressources de l'API Compute Engine pour l'authentification mTLS au sein d'un réseau maillé (cliquez pour agrandir)

Le schéma suivant illustre le flux de trafic et répertorie les ressources de l'API Compute Engine que vous configurez pour activer l'authentification mTLS. Le proxy side-car local placé devant le pod GKE du service B est le point de terminaison de la communication.

Ressources de l'API Compute Engine et flux de trafic pour mTLS au sein d'un réseau maillé (cliquez pour agrandir)

La règle de point de terminaison effectue les opérations suivantes:

1. Sélectionne un ensemble de points de terminaison à l'aide d'un outil de mise en correspondance des points de terminaison et, éventuellement, de ports sur ces points de terminaison.

   1. L'outil de mise en correspondance des points de terminaison vous permet de spécifier des règles qui déterminent si un client Cloud Service Mesh reçoit la configuration. Ces règles sont basées sur les métadonnées xDS que les données fournie au plan de contrôle. Dans ce cas, Cloud Service Mesh.

      Vous pouvez ajouter des étiquettes au client Cloud Service Mesh comme suit:

      • Vous pouvez spécifier manuellement ces métadonnées dans le fichier d'amorçage du client Cloud Service Mesh.

      • Vous pouvez également les renseigner automatiquement lorsque vous utilisez GKE en ajoutant les paires clé/valeur à la section env des fichiers demo_server.yaml ou demo_client.yaml. Ces valeurs sont fournies dans le guide de configuration Envoy et dans le guide de configuration gRPC sans proxy.

        Par exemple, avec Envoy uniquement, vous pouvez ajouter le préfixe ISTIO_META_ à la clé. Les noms de variables d'environnement proxy qui commencent par ISTIO_META_ sont inclus dans l'amorçage généré et envoyés au serveur xDS.

        - name: ISTIO_META_app
          value: 'review'
        - name: ISTIO_META_version
          value: 'canary'
        

   2. Si vous spécifiez un port, les règles référencées dans la règle de point de terminaison ne s'appliquent qu'aux requêtes entrantes qui spécifient le même port. Si vous ne spécifiez pas de port, les stratégies sont appliquées aux requêtes entrantes qui spécifient un port qui se trouve également dans le champ TRAFFICDIRECTOR_INBOUND_BACKEND_PORTS, qui est fourni au client Cloud Service Mesh dans ses informations d'amorçage.

2. Référence les règles TLS du client, TLS du serveur et les règles d'autorisation qui configurent les points de terminaison auxquels les requêtes aboutissent.

La configuration de modes TLS incompatibles peut entraîner une interruption des communications. Par exemple, si vous définissez OPEN sur le service de backend global ou laissez le champ de règle TLS client vide et que vous définissez MTLS en tant que valeur de la règle TLS de serveur associée à la règle de point de terminaison, les tentatives de communication échouent. En effet, les points de terminaison configurés pour n'accepter que mTLS rejettent les tentatives pour établir des canaux de communication non authentifiés.

Notez la distinction entre une règle TLS client et une règle TLS de serveur associée à un service de backend global et à une règle de point de terminaison, respectivement :

• La règle TLS cliente est appliquée au service de backend global. Elle indique au proxy Envoy ou au client sans proxy le mode TLS, l'identité et la validation de l'appairage à utiliser lors de la communication avec le service.
• La règle TLS du serveur est associée à la règle de point de terminaison et indique au serveur quel mode TLS, quelle approche sur les identités et les validations d'appairage utiliser pour les connexions entrantes.

Activer TLS pour une passerelle d'entrée

Une fois que vous avez configuré mTLS pour les communications dans le réseau maillé, vous pouvez sécuriser le trafic qui entre dans votre réseau maillé, appelé trafic entrant. Cloud Service Mesh peut configurer votre plan de données de manière à exiger que le trafic entrant utilise les canaux de communication chiffrés par TLS.

Pour atteindre cet objectif, choisissez l'une des options d'architecture suivantes :

• Les services du réseau maillé mettent fin au protocole TLS pour le trafic provenant d'un équilibreur de charge. Dans ce modèle, chaque service du réseau maillé est configuré en tant que backend dans la configuration de l'équilibreur de charge. En particulier dans le mappage d'URL de l'équilibreur de charge.
• Une passerelle d'entrée interrompt le protocole TLS pour le trafic provenant d'un équilibreur de charge, avant de transférer le trafic vers les services du réseau maillé. Dans ce modèle, un service dédié du réseau maillé, la passerelle d'entrée, est configuré en tant que backend dans la configuration de l'équilibreur de charge. Plus spécifiquement, dans le mappage d'URL de l'équilibreur de charge.

Les deux options sont expliquées dans cette section.

Les services du maillage interrompent le protocole TLS pour le trafic provenant d'un équilibreur de charge.

Si vous souhaitez mettre vos services à la disposition de clients en dehors de Google Cloud, vous pouvez utiliser équilibreur de charge d'application externe. Les clients envoient du trafic à l'adresse IP virtuelle (VIP) Anycast globale de l'équilibreur de charge, qui transfère ensuite ce trafic aux services de votre réseau maillé. Cela signifie qu'il existe deux connexions lorsqu'un client externe doit accéder à un service du réseau maillé.

TLS vers un service du réseau maillé (cliquez pour agrandir)

Le même schéma s'applique lorsque vous utilisez un équilibreur de charge d'application interne. Le trafic provenant des clients internes atteint d'abord l'équilibreur de charge, qui établit ensuite une connexion avec le backend.

Pour sécuriser les deux connexions, procédez comme suit :

1. Sécurisez la connexion entre le client et l'équilibreur de charge à l'aide d'un équilibreur de charge d'application externe.
2. Configurez l'équilibreur de charge pour qu'il utilise les protocoles HTTPS ou HTTP/2 lorsqu'il tente d'établir une connexion avec des services du réseau maillé.
3. Configurer Cloud Service Mesh pour que vos clients Cloud Service Mesh s'arrêtent HTTPS et de présenter des certificats au client, qui, dans ce cas, un équilibreur de charge HTTP(S) externe global.

Pour en savoir plus sur les étapes 1 et 2, consultez la page Configurer un équilibreur de charge HTTPS externe multirégional basé sur le contenu.

Lorsque vous configurez la sécurité de Cloud Service Mesh, vous configurez diverses Ressources de l'API Compute Engine. Ces ressources sont distinctes de celles que vous configurez pour l'équilibreur de charge. Vous créez un ensemble de Les ressources de l'API Compute Engine (règle de transfert globale, proxy cible, mappage d'URL, et les services de backend globaux) pour l'équilibreur de charge et configurer Cloud Service Mesh avec les API de routage de services. De plus, dans le backend, ressource de service, l'équilibreur de charge utilise le schéma INTERNAL_MANAGED, et Cloud Service Mesh utilise le schéma d'équilibrage de charge INTERNAL_SELF_MANAGED

À l'étape 3, vous configurez Cloud Service Mesh de sorte que vos clients Cloud Service Mesh mettent fin au protocole HTTPS et présentent des certificats aux clients :

Ressources de l'API Compute Engine pour le protocole TLS vers les services du réseau maillé (cliquez pour agrandir)

.

Dans ce tutoriel, vous allez effectuer les opérations suivantes :

1. Créez un serverTlsPolicy : configurez serverCertificate sur la ressource serverTlsPolicy.
2. Créez une règle de point de terminaison :
   1. Référencez la règle TLS du serveur dans le champ authentication.
   2. Définissez un objet EndpointMatcher pour sélectionner les entités de plan de données xDS qui doivent appliquer l'authentification sur le trafic entrant.
   3. Si vous le souhaitez, définissez un TrafficPortSelector qui applique la uniquement lorsque les requêtes entrantes sont adressées au port spécifié le client Cloud Service Mesh.

Étant donné que l'équilibreur de charge d'application externe est déjà configuré pour initier des connexions TLS aux services de votre réseau maillé, Cloud Service Mesh n'a besoin que de configurer vos clients Cloud Service Mesh pour qu'il mette fin aux connexions TLS.

La passerelle d'entrée interrompt le protocole TLS pour le trafic provenant d'un équilibreur de charge avant de transférer le trafic aux services du maillage.

Si vous souhaitez exposer une passerelle d'entrée à votre équilibreur de charge uniquement, vous pouvez utiliser le modèle de déploiement de la passerelle d'entrée. Dans ce modèle, l'équilibreur de charge ne s'adresse pas directement aux services de votre réseau maillé. Au lieu de cela, un proxy intermédiaire se trouve en périphérie de votre réseau maillé et achemine le trafic vers les services à l'intérieur du réseau maillé, selon la configuration qu'il reçoit de Cloud Service Mesh. Le proxy intermédiaire peut être un proxy Envoy que vous avez déployé sur des instances de machine virtuelle (VM) dans un groupe d'instances géré Compute Engine.

TLS vers une passerelle d'entrée avec mTLS au sein d'un réseau maillé (cliquez pour agrandir)

.

Du point de vue de la sécurité, vous configurez la passerelle d'entrée pour qu'elle mette fin au protocole TLS, puis vous configurez éventuellement des connexions au sein de votre réseau maillé pour qu'elles soient protégées par mTLS. Ces connexions incluent des connexions entre la passerelle d'entrée et vos services de réseau maillé, ainsi qu'entre vos services de réseau maillé.

Du point de vue de la configuration, effectuez les opérations suivantes:

1. Configurer votre maillage de services et activer l'authentification mTLS pour les communications au sein du maillage (comme expliqué précédemment).
2. Configurer votre équilibreur de charge pour acheminer le trafic vers la passerelle d'entrée et initier des connexions à l'aide du protocole HTTPS (comme expliqué précédemment).
3. Créer un ensemble de ressources d'e lAPI Compute Engine représentant la passerelle d'entrée et la règle TLS du serveur.

Pour la troisième étape, configurez Cloud Service Mesh de sorte qu'il arrête le protocole HTTPS et présente les certificats comme suit :

1. Créez une ressource Mesh pour représenter le maillage.

2. Créez une ressource Route qui pointe vers les services de backend globaux appropriés, puis associez-la à la ressource Mesh.

3. Créez une règle TLS de serveur : configurez serverCertificate.

4. Créer une ressource Gateway pour représenter le maillage de services géré de passerelle d'entrée externe.

5. Associez la ressource de règle TLS du serveur à la ressource Gateway.

Le modèle de passerelle d'entrée est particulièrement utile dans les grandes organisations qui utilisent un VPC partagé. Dans un tel cas, une équipe peut n'autoriser l'accès à ses services que via une passerelle d'entrée. Dans le diagramme précédent, lorsque vous configurez la règle de transfert globale pour l'équilibreur de charge, vous fournissez une adresse IP différente (10.0.0.2 dans cet exemple) de celle fournie lors de la configuration du maillage (10.0.0.1 dans cet exemple). Les clients qui communiquent via une entité de plan de données xDS configurée par Cloud Service Mesh peuvent utiliser cette adresse pour accéder à la passerelle d'entrée.

Par exemple, supposons ce qui suit:

• Deux projets de service (1 et 2), tous deux associés au même réseau VPC partagé.

• Le projet de service 1 contient un maillage de services configuré par Cloud Service Mesh.

  Le projet de service 1 a configuré un réseau maillé et une passerelle d'entrée. Cette passerelle d'entrée est accessible à partir de l'adresse/adresse IP virtuelle 10.0.0.2.

• Le projet de service 2 contient un maillage de services configuré par Cloud Service Mesh.

  Le projet de service 2 peut disposer ou non de sa propre passerelle d'entrée.

• Cloud Service Mesh configure les clients Cloud Service Mesh dans chaque service projet. Les clients sont amorcés pour utiliser le même réseau.

Compte tenu de cette configuration, les clients du maillage du projet de service 2 peuvent communiquer avec la passerelle d'entrée du projet de service 1 à l'aide de l'adresse IP virtuelle 10.0.0.2. Cela permet aux propriétaires du projet de service 1 de configurer le routage, la sécurité et d'autres règles spécifiques au trafic entrant dans le réseau maillé. En effet, les propriétaires du projet de service 1 peuvent dire à d'autres utilisateurs que les clients de votre réseau maillé peuvent accéder à mes services sur 10.0.0.2.

Limites

La sécurité du service Cloud Service Mesh n'est compatible qu'avec les dans GKE. Vous ne pouvez pas déployer la sécurité de service avec Compute Engine.

Étape suivante

• Pour configurer la sécurité du service Cloud Service Mesh avec des proxys Envoy, consultez la page Configurer la sécurité du service Cloud Service Mesh avec Envoy
• Pour configurer la sécurité du service Cloud Service Mesh avec des applications gRPC sans proxy, procédez comme suit : consultez la page Configurer la sécurité du service Cloud Service Mesh avec gRPC sans proxy.