Anthos Service Mesh et Traffic Director sont désormais Cloud Service Mesh. Pour en savoir plus, consultez la page Présentation de Cloud Service Mesh.

Cette page a été traduite par l'API Cloud Translation.

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

Ce document décrit des cas d'utilisation courants de la sécurité de 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é du service 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 TLS mutuelle (mTLS) dans un maillage de services. — Authentification mutuelle TLS (mTLS) dans un maillage de services (cliquez pour agrandir)

La section suivante n'aborde pas les ressources Mesh, Gateway et Route. Ces ressources d'API sont nécessaires pour créer votre maillage et acheminer le trafic, 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 mTLS dans un réseau maillé. — 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 :

Créez une règle TLS (Transport Layer Security) cliente.
Créez une règle TLS de serveur.
Mettez à jour le champ securitySettings dans vos services de backend globaux existants pour référencer la nouvelle règle TLS du client.
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 un 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ées 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.

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 et flux de trafic de l'API Compute Engine pour mTLS dans un réseau maillé. — 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:

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 l'entité de plan de données fournit 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 de votre 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 règles sont appliquées aux requêtes entrantes qui spécifient un port qui figure également dans le champ TRAFFICDIRECTOR_INBOUND_BACKEND_PORTS, qui est fourni au client Cloud Service Mesh dans ses informations d'amorçage.
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 du client est appliquée au service de backend global. Il indique au proxy Envoy ou au client sans proxy le mode TLS, l'identité et l'approche de validation de pairs à utiliser pour adresser le service.
La règle TLS du serveur est associée à la règle de point de terminaison. Il indique au serveur le mode TLS, l'identité et l'approche de validation des pairs à 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 pour exiger que le trafic entrant utilise des 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 que vos services soient disponibles pour des clients extérieurs à Google Cloud, vous pouvez utiliser un é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é. — 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 :

Sécurisez la connexion entre le client et l'équilibreur de charge à l'aide d'un équilibreur de charge d'application externe.
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é.
Configurez Cloud Service Mesh de sorte que vos clients Cloud Service Mesh interrompent le protocole HTTPS et présentent des certificats au client, qui, dans ce cas, est l'équilibreur de charge.

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 ressources de l'API Compute Engine (règle de transfert globale, proxy cible, mappage d'URL et services de backend globaux) pour l'équilibreur de charge et configurez Cloud Service Mesh avec les API de routage de services. En outre, dans la ressource de service de backend, l'équilibreur de charge utilise le schéma d'équilibrage de charge INTERNAL_MANAGED, tandis que Cloud Service Mesh utilise le schéma d'équilibrage de charge INTERNAL_SELF_MANAGED.

À l'étape 3, vous allez configurer Cloud Service Mesh afin que vos clients Cloud Service Mesh interrompent HTTPS et présentent des certificats aux clients.

Ressources API Compute Engine pour le TLS vers un service du réseau maillé. — 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 :

Créez un serverTlsPolicy: configurez serverCertificate sur la ressource serverTlsPolicy.
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. Vous pouvez également définir un TrafficPortSelector qui n'applique les règles que lorsque des requêtes entrantes sont envoyées au port spécifié sur 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 mettre 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 à la périphérie de votre maillage et achemine le trafic vers les services à l'intérieur de celui-ci, en fonction de la configuration reçue 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 dans un réseau maillé. — 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:

Configurer votre maillage de services et activer l'authentification mTLS pour les communications au sein du maillage (comme expliqué précédemment).
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).
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 pour mettre fin au protocole HTTPS et présenter des certificats comme suit:

Créez une ressource Mesh pour représenter le maillage.
Créez une ressource Route qui pointe vers les services de backend globaux appropriés et associez la ressource Route à la ressource Mesh.
Créez une règle TLS de serveur : configurez serverCertificate.
Créez une ressource Gateway pour représenter la passerelle d'entrée gérée Cloud Service Mesh.
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 schéma précédent, lorsque vous configurez la règle de transfert globale pour l'équilibreur de charge, vous fournissez une adresse IP différente (dans cet exemple, 10.0.0.2) de celle fournie lors de la configuration du maillage (dans cet exemple, l'adresse du réseau maillé est 10.0.0.1). Les clients qui communiquent via une entité de plan de données xDS configurée dans 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 projet de service. 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 GKE. Vous ne pouvez pas déployer la sécurité du service avec Compute Engine.

Étapes suivantes

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, consultez la page Configurer la sécurité du service Cloud Service Mesh avec gRPC sans proxy.