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

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

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 :

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 EndpointMatcher pour sélectionner les clients Traffic Director qui doivent appliquer l'authentification sur le trafic entrant.
  
  Sélectionner des clients Traffic Director se base sur les libellés spécifiés dans la configuration d'amorçage du client Traffic Director. 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 Traffic Director. 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 Traffic Director 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, Traffic Director.
  
  Vous pouvez ajouter des libellés au client Traffic Director comme suit :
  - Vous pouvez spécifier manuellement ces métadonnées dans le fichier d'amorçage du client Traffic Director.
  - 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 Traffic Director 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 des 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. Traffic Director 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 accessibles à 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 Traffic Director de sorte que vos clients Traffic Director interrompent le protocole HTTPS et présentent des certificats au client. Dans ce cas, il s'agit de 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é Traffic Director, 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 Traffic Director, qui possède le schéma d'équilibrage de charge INTERNAL_SELF_MANAGED.

À l'étape 3, vous configurez Traffic Director de sorte que vos clients Traffic Director 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 :

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

Étant donné que l'équilibreur de charge d'application externe est déjà configuré pour lancer des connexions TLS aux services de votre réseau maillé, il suffit de configurer vos clients Traffic Director pour qu'ils mettent 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é. À 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 Traffic Director. 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 Traffic Director de sorte qu'il arrête le protocole HTTPS et présente les certificats comme suit:

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é.
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.
Créez une règle TLS de serveur : configurez serverCertificate.
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. Dans le schéma précédent, lorsque vous configurez la règle de transfert globale, vous devez fournir 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 par Traffic Director 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 Traffic Director.

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 Traffic Director.

Le projet de service 2 peut disposer ou non de sa propre passerelle d'entrée.
Traffic Director configure les clients Traffic Director 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 Traffic Director n'est compatible qu'avec GKE. Vous ne pouvez pas déployer la sécurité des services avec Compute Engine.

Étapes suivantes

Pour configurer la sécurité du service Traffic Director avec des proxys Envoy, consultez la page Configurer la sécurité du service Traffic Director avec Envoy.
Pour configurer la sécurité du service Traffic Director avec des applications gRPC sans proxy, consultez la page Configurer la sécurité du service Traffic Director avec une infrastructure gRPC sans proxy.