Cas d'utilisation de la sécurité des services (ancien)

Ce document décrit des cas d'utilisation courants de la sécurité dans 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.

Ce document s'applique aux configurations utilisant les API d'équilibrage de charge. Il s'agit d'un ancien document.

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 omet la discussion concernant la règle de transfert globale, le proxy HTTPS cible et le mappage d'URL. Ces ressources de l'API Compute Engine sont nécessaires pour créer votre maillage, mais vous n'avez pas besoin de les mettre à jour pour activer l'authentification 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 :

  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 libellés "mesh-service":"true" sont configurés sur la règle du 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 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)

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:

  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. Cet outil vous permet de spécifier des règles 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 libellés au client Cloud Service Mesh comme suit :

      • Vous pouvez spécifier manuellement ces métadonnées dans votre 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 règles sont appliquées aux requêtes entrantes qui spécifient un port qui est également 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 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 :

  1. Sécurisez la connexion entre le client et l'équilibreur de charge à l'aide de 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é 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. En d'autres termes, vous créez deux ensembles de ressources d'API Compute Engine (règle de transfert globale, proxy cible, mappage d'URL et services de backend globaux) avec des schémas d'équilibrage de charge différents :

  • Un ensemble de ressources configure votre équilibreur de charge, qui possède le schéma d'équilibrage de charge INTERNAL_MANAGED.
  • L'autre ensemble de ressources configure Cloud Service Mesh, 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 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 :

  1. Créez une règle TLS de serveur : configurez terminationTls sur transportAuthentication.
  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.

Comme l'équilibreur de charge d'application externe est déjà configuré pour lancer TLS aux services de votre réseau maillé, Cloud Service Mesh n'a besoin configurer vos clients Cloud Service Mesh pour interrompre les 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é. À la place, un proxy intermédiaire se trouve à la périphérie de votre réseau maillé et achemine le trafic vers les services à l'intérieur du maillage, 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:

  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 règle de transfert globale et un proxy HTTPS cible pour représenter le chemin d'accès du trafic entrant dans votre réseau maillé.

  2. Associez le mappage d'URL existant pour votre maillage à ce proxy HTTPS cible. Le mappage d'URL contient déjà des références aux différents services de backend globaux de votre maillage, en fonction de la configuration fournie lors de la configuration du maillage et de mTLS.

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

  4. Associez la ressource de règle TLS du serveur à votre proxy HTTPS cible.

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. Au cours de la Dans ce schéma, lorsque vous configurez la règle de transfert globale, vous fournissez une adresse IP différente (dans cet exemple, 10.0.0.2) de celle fournie lorsque vous configurez le réseau maillé (dans cet exemple, l'adresse du réseau maillé est 10.0.0.1). Clients qui communiquent via un plan de données xDS configuré dans Cloud Service Mesh peut 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 via l'adresse 10.0.0.2 (VIP).

  • 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