Sécurité des services (ancienne)

Ce document présente la sécurité des services avec Cloud Service Mesh à l'aide des API d'équilibrage de charge. Il est destiné aux utilisateurs de Cloud Service Mesh qui souhaitent ajouter l'authentification, le chiffrement et l'autorisation à leurs déploiements. Ce dans ce document suppose que vous connaissez Cloud Service Mesh avec Envoy et avec des applications gRPC sans proxy.

Ce document s'applique aux configurations utilisant les API d'équilibrage de charge. Si vous utilisez les API de routage de services, consultez la section Sécurité des services. Ceci est un ancien document.

Cloud Service Mesh vous permet de sécuriser les communications de service à service dans vos réseau maillé. Dans le maillage, chaque service possède une identité. Les fonctionnalités suivantes facilitent la communication sécurisée :

  • Authentification et chiffrement utilisant TLS (Transport Layer Security) et l'authentification mutuelle TLS (mTLS) pour Cloud Service Mesh avec Envoy et Cloud Service Mesh avec des applications gRPC sans proxy. Les règles TLS client et les règles TLS du serveur déterminent si les services doivent prouver leur identité les uns aux autres et utiliser des canaux de communication chiffrés.
  • Autorisation, basée sur les caractéristiques du client et de la requête Les règles d'autorisation déterminent si un service est autorisé à accéder à un autre service et quelles actions sont autorisées.

L'utilisation de certificats et de clés fournis par une autorité de certification privée, Certificate Authority Service de Google, vous permet d'assurer plus facilement la sécurité des services. CA Service fournit des certificats de maillage GKE. Les certificats du maillage GKE et Cloud Service Mesh vous permettent de déployer automatiquement de certificats et faire en sorte que les charges de travail les utilisent. Modifiez vos pods pour permettre aux charges de travail de recevoir et d'utiliser des identifiants mTLS. La sécurité du service Cloud Service Mesh n'est disponible que pour les charges de travail basées sur GKE.

Dans les architectures modernes basées sur des microservices, des services plus petits et plus ciblés remplacent les applications monolithiques de grande taille. Les appels de service communiquent entre eux sur le réseau. Ces appels, qui correspondaient à des appels en cours dans des applications monolithiques, présentent des défis liés à la sécurité. Il est donc préférable de les authentifier, de les chiffrer et de les autoriser. Ces étapes sont conformes au principe de zéro confiance, dans lequel tout le trafic réseau est considéré comme présentant un risque, que le trafic provienne de l'intérieur ou de l'extérieur du réseau.

Le modèle de conception du maillage de services sépare la complexité liée aux communications de service à service de la logique métier. C'est le plan de données qui gère cette complexité. En plus de réduire la complexité des applications, le modèle de conception du maillage de services permet d'utiliser des modèles de sécurité qui pourraient autrement être difficilement mis en œuvre et gérés.

Dans ce modèle, les side-cars gRPC ou Envoy sans proxy authentifient et chiffrent les communications de manière sécurisée en obtenant les informations de configuration de Cloud Service Mesh et les certificats d'un pool CA Service.

Ces fonctionnalités de sécurité facilitent le processus de déploiement de Cloud Service Mesh en fournissant les éléments suivants :

  • Provisionnement automatique des clés et des certificats pour tous les services de votre maillage
  • La rotation automatique des clés et des certificats permet de renforcer la sécurité.
  • L'intégration à Google Kubernetes Engine (GKE) permet d'exploiter toutes ses fonctionnalités, telles que les descripteurs de déploiement et les libellés.
  • Haute disponibilité des services gérés par Google, y compris Cloud Service Mesh et les pools d'autorités de certification privées gérés par CA Service.
  • Sécurité liée à Google IAM (Identity and Access Management) : autorisation de service basée sur les comptes de service Google autorisés.
  • Interopérabilité transparente avec vos charges de travail basées sur Envoy et sans proxy. Par exemple, un service peut être situé derrière un proxy Envoy, mais le client utilise la sécurité du maillage de services gRPC sans proxy, ou inversement. À l'inverse, un service peut se trouver derrière la sécurité du maillage de services sans proxy gRPC, mais le client utilise un proxy Envoy.

Communications sécurisées de service à service

Cloud Service Mesh fournit des autorisations et une sécurité de service à service avec le chiffrement et l’authentification qui utilisent TLS. Les règles TLS Client et les règles TLS du serveur permettent aux services d'effectuer les opérations suivantes :

  • Vérifiez et validez leurs identités.
  • Chiffrez les sessions de communication à l'aide de TLS et mTLS.

Dans un maillage de services, le plan de données gère ce type de sécurité afin que les applications n'aient pas à prendre de dispositions spéciales pour être sécurisées.

Les règles d'autorisation vous permettent d'interdire ou d'autoriser l'accès conformément aux règles que vous définissez.

Utiliser TLS pour le chiffrement

Lorsqu'un service appelle un autre service via le protocole HTTP, HTTP/2 ou gRPC, le trafic qui transite par le réseau est en texte brut. Ce trafic peut être soumis à des attaques MITM, dans lesquelles un pirate intercepte le trafic, et inspecte ou manipule le contenu.

Pour atténuer ce problème potentiel, vous pouvez utiliser HTTP, HTTP/2 ou gRPC sur TLS avec Cloud Service Mesh. Lorsque vous utilisez ces protocoles via TLS, le trafic entre le client et le serveur est chiffré à l'aide de TLS basé sur le certificat du serveur. Le trafic n'est plus en texte brut, ce qui réduit la probabilité qu'un pirate informatique puisse intercepter, inspecter ou manipuler son contenu.

Utiliser TLS pour l'authentification

Lorsqu'un service appelle un autre service, posez-vous les questions suivantes :

  • Comment un client sait-il qu'il reçoit une réponse du serveur approprié plutôt qu'un imposteur ? Par exemple, dans une interaction classique de requête-réponse basée sur HTTP, le client ne vérifie pas l'identité du serveur.

  • Que se passe-t-il si un pirate informatique intercepte ce trafic ? Par exemple, le trafic HTTP n'est pas chiffré, de sorte que toute personne qui le reçoit peut inspecter son contenu. Il s'agit d'une attaque MITM.

Pour résoudre ces problèmes, vous pouvez utiliser HTTP, HTTP/2 et gRPC via TLS. Lors de ces échanges entre un client et un serveur, le serveur doit utiliser un certificat de serveur pour prouver son identité au client. Les requêtes et les réponses sont ensuite chiffrées à l'aide de TLS.

Authentification TLS mutuelle

Lorsque Cloud Service Mesh configure la mise en réseau des applications à la fois pour le client serveur, par exemple en configurant un proxy Envoy côté client un autre proxy Envoy côté serveur, vous pouvez profiter des fonctionnalités avancées des modèles d'authentification tels que l'authentification mutuelle.

Dans un échange HTTP via TLS, qui n'est pas basé sur l'authentification mutuelle, le serveur dispose d'un certificat qu'il utilise pour chiffrer les communications entre le client et le serveur. Le client peut vérifier l'identité du serveur en vérifiant la signature que le serveur renvoie lors du handshake TLS. Cependant, le serveur ne valide pas l'identité du client.

Lorsque l'authentification mutuelle est activée, le client dispose également d'un certificat. Le client vérifie l'identité du serveur, comme décrit dans le paragraphe précédent, et le serveur peut également valider l'identité du client. Les certificats client et serveur sont utilisés pour chiffrer le canal de communication. Cela permet également au serveur d'autoriser des clients en fonction de l'identité du client validé.

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

Autoriser les appels de service

Vous pouvez choisir d'autoriser ou de refuser l'accès aux services à l'aide de règles d'autorisation. Avec Cloud Service Mesh, vous pouvez définir des règles d'autorisation et de refus pour autoriser l'accès en fonction des paramètres de requête. Vous pouvez baser ces règles sur les paramètres de couche 3 et couche 7, y compris l'ID client, qui est dérivé de client-cert dans une connexion mTLS, l'adresse IP source, la correspondance de l'hôte, la correspondance de méthode et la correspondance d'en-tête. Le schéma suivant montre l'autorisation avec les proxys Envoy. Le processus est semblable à celui des clients gRPC.

Autorisation dans un maillage de services.
Autorisation dans un maillage de services avec Envoy (cliquez pour agrandir)

Limiter l'accès à l'aide d'une autorisation

Une bonne pratique dans un maillage de services consiste à respecter le principe du moindre privilège. Vous pouvez respecter ce principe en limitant l'accès au service aux seuls appelants qui dépendent du service. Lorsqu'un appelant tente d'accéder à un service pour lequel il n'est pas autorisé, la tentative est rejetée.

Avec Cloud Service Mesh, vous pouvez configurer des règles d'autorisation qui autorisent votre plan de données pour autoriser ou refuser l'accès aux services en fonction de règles que vous définissez. Ces règles se composent de deux éléments :

  • Action : autoriser ou refuser
  • Liste des règles

Lorsqu'une requête ou un RPC est envoyé, le client Cloud Service Mesh sur la service détermine s'il existe une correspondance de règle. En cas de correspondance, la requête ou le RPC est autorisé ou refusé. Vous pouvez définir une règle à mettre en correspondance avec des attributs, tels que les suivants :

  • Le compte de service Kubernetes du service appelant, lorsque mTLS est utilisé
  • Adresse IP (ou plage d'adresses) du service appelant
  • Le ou les ports du service de destination
  • Les attributs HTTP de la requête, y compris les noms d'hôte, les méthodes et les en-têtes HTTP définis par l'utilisateur.

dénomination sécurisée

En tant que mécanisme de sécurité supplémentaire, vous pouvez configurer la appellation sécurisée avec Cloud Service Mesh. Cela vous permet de définir une liste de noms autorisés ou d'identités SPIFFE (Secure Production Identity Framework for Everyone) pour un service particulier auquel un client tente de se connecter. Lors de l'échange TLS, le backend du service renvoie un certificat X.509 au client. Le client inspecte ensuite le certificat pour vérifier que le certificat X.509 correspond à l'une des identités des noms ou SPIFFE. Pour en savoir plus sur les identités SPIFFE, consultez la page Secure Production Identity Framework for Everyone.

Sécuriser le trafic au niveau d'une passerelle

Pour configurer vos passerelles, vous pouvez utiliser Cloud Service Mesh. Une passerelle est un proxy Envoy autonome qui agit généralement comme l'un des éléments suivants:

  • Une passerelle d'entrée qui gère le trafic qui entre dans un réseau maillé ou un autre domaine
  • Une passerelle de sortie qui gère le trafic quittant un réseau maillé ou un autre domaine
  • Un proxy inverse ou un proxy intermédiaire qui distribue le trafic entrant entre un ou plusieurs services

Les clients qui souhaitent envoyer du trafic vers le maillage ou depuis le maillage envoient du trafic à la passerelle. La passerelle traite ensuite les requêtes en fonction des règles que vous avez définies avec Cloud Service Mesh. Par exemple, vous pouvez forcer l'utilisation du protocole TLS pour le trafic entrant dans votre réseau maillé (via la passerelle d'entrée).

Composants de sécurité

La sécurité du service Cloud Service Mesh est compatible avec les règles TLS côté client, TLS de serveur et les règles d'autorisation. Créez ces stratégies de sorte que Cloud Service Mesh puisse configurer votre plan de données et activer les fonctionnalités de sécurité. Pour créer ou mettre à jour ces règles, vous n'avez pas besoin de modifier vos applications.

Modes de chiffrement et modes d'authentification compatibles

Lorsqu'un service appelle un autre service, la première étape pour établir une communication sécurisée consiste à demander à chaque service de prouver son identité à l'autre service. Le degré pour lequel un service doit prouver son identité est basé sur le mode TLS que vous configurez.

Vous pouvez configurer les niveaux de sécurité suivants :

  • Non chiffré/non authentifié
  • TLS
  • Authentification TLS mutuelle (mTLS)
  • Permissif : authentification mTLS ou non chiffrée/non authentifiée, selon la manière dont le client initie la connexion.

Certificats et autorités de certification

Les certificats et une autorité de certification de confiance (CA) constituent la base d'une confiance dans un système distribué tel qu'un maillage de services. À l'aide de certificats, les services peuvent prouver leur identité et valider les identités qui leur sont présentées de différentes manières :

  • Un service qui souhaite prouver son identité à un autre service présente son certificat à l'autre service. Une autorité de certification (CA) qui fait confiance aux deux services et signe ce certificat.
  • Le service qui reçoit ce certificat peut vérifier qu'il provient d'une autorité de certification de confiance.

Cloud Service Mesh n'est pas une autorité de certification. Pour activer les communications sécurisées, vous devez configurer un mécanisme qui effectue les opérations suivantes :

  • Provisionne les identités et les certificats.
  • Rend les certificats disponibles pour les clients Cloud Service Mesh, tels que les proxys Envoy, configurés par Cloud Service Mesh.

Cloud Service Mesh est compatible avec le service CA de Google. Les guides de configuration pour Envoy et gRPC sans proxy incluent des instructions de configuration (pour en savoir plus, consultez la section Étapes suivantes).

Architecture et ressources

Cloud Service Mesh inclut l'espace de noms de l'API Network Security, composé de trois ressources de l'API Google Cloud, qui vous permettent de spécifier les règles de sécurité à appliquer à votre plan de données.

Deux ressources d'API Google Cloud sont compatibles avec l'authentification dans le maillage : les règles TLS clientes et les règles TLS du serveur. Une troisième ressource, la règle d'autorisation, accepte l'autorisation.

L'espace de noms de l'API Network Services inclut la ressource de stratégie de point de terminaison, qui permet à Cloud Service Mesh de fournir la configuration (TLS du serveur, TLS des clients et règles d'autorisation) aux points de terminaison. Les points de terminaison sont les clients Cloud Service Mesh qui mettent fin à une communication entrante d'un autre client Cloud Service Mesh.

Pour activer le service de sécurité, utilisez le proxy HTTPS ou gRPC cible dans votre déploiement. Vous ne pouvez pas utiliser le proxy HTTP cible ou le proxy TCP cible.

Règle TLS du client

Une règle TLS client vous permet de spécifier le mode TLS côté client et les informations du fournisseur de certificats à appliquer à votre plan de données. Les règles TLS sont compatibles avec l'authentification TLS et mTLS. Les règles TLS clientes doivent être associées à une ressource de service de backend global.

Lorsque vous configurez TLS, vous devez fournir un mécanisme permettant au client de valider le certificat qu'il reçoit du serveur lors de l'échange TLS à l'aide du champ d'API serverValidationCa. Le client utilise ces informations pour obtenir un certificat de validation qu'il peut utiliser pour valider le certificat de serveur.

Lorsque vous configurez l'authentification mTLS, vous devez également fournir un mécanisme qui permet au client d'obtenir son certificat et sa clé privée à l'aide du champ d'API clientCertificate. Le client utilise ces informations pour présenter un certificat au serveur lors du handshake TLS.

Dans cette version, Cloud Service Mesh prend en charge une autorité de certification gérée, Service CA : La configuration est simple : vous spécifiez le nom du plug-in google_cloud_private_spiffe lorsque vous configurez le fournisseur de certificats. Vos clients xDS chargent ainsi les certificats et les clés d'un emplacement statique. Au préalable, vous devez configurer les pools CA Service et activer les certificats de maillage sur votre cluster GKE.

Règle TLS du serveur

Une règle TLS de serveur (ressource ServerTlsPolicy) vous permet de spécifier le mode TLS côté serveur et les informations de fournisseur de certificats à appliquer à votre plan de données. Les règles TLS du serveur sont compatibles avec les protocoles TLS, mTLS et, avec Envoy uniquement, l'authentification Open_or_mTLS. Les règles TLS du serveur peuvent être associées à la ressource de proxy HTTPS cible ou à une ressource de règle de point de terminaison.

Noms d'objets alternatifs

Lorsque vous configurez le champ securitySettings d'un service de backend global, vous pouvez fournir une liste de noms d'objet de remplacement dans le champ subjectAltNames. Lorsqu'un client lance un handshake TLS avec l'un des backends du service, le serveur présente son certificat X.509. Le client inspecte le champ subjectAltName du certificat. Si le champ contient l'une des valeurs spécifiées, la communication continue. Ce mécanisme est décrit plus en détail dans la section Attribuer des noms sécurisés.

Règle d'autorisation

Une règle d'autorisation (ressource AuthorizationPolicy) spécifie la manière dont un serveur autorise les requêtes entrantes ou les RPC. Il peut être configuré pour autoriser ou refuser une requête entrante ou un RPC en fonction de divers paramètres, tels que l'identité du client ayant envoyé la requête, l'hôte, les en-têtes et d'autres attributs HTTP. Une règle d'autorisation peut être associée à la ressource de proxy HTTPS cible ou à une ressource de règle de point de terminaison.

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é du service avec Compute Engine.

Limites applicables aux applications gRPC sans proxy

La sécurité des services pour les services gRPC sans proxy présente les limites suivantes :

  • Cette version est limitée à Java, Python, C++ et Go.

Étape suivante