Sécurité des services

Ce document présente la sécurité des services avec Cloud Service Mesh. Il est destiné aux utilisateurs de Cloud Service Mesh qui souhaitent ajouter l'authentification, le chiffrement et l'autorisation à leurs déploiements. Dans ce document, nous partons du principe que vous connaissez bien la présentation de Cloud Service Mesh et les applications gRPC sans proxy.

Remarque :Ce guide n'est compatible qu'avec Cloud Service Mesh avec les API Google Cloud et non avec les API Istio. Pour en savoir plus, consultez la présentation de Cloud Service Mesh.

Cloud Service Mesh vous permet de sécuriser les communications de service à service dans votre maillage. 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. La fonctionnalité de certificats de maillage GKE et Cloud Service Mesh vous permettent de déployer automatiquement ces certificats et d'autoriser les charges de travail à les utiliser. 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 actuellement 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 une autorisation, ainsi qu'une sécurité de service à service avec le chiffrement et l'authentification utilisant 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 via 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 pour le client et le serveur (par exemple, en configurant un proxy Envoy côté client et un autre proxy Envoy côté serveur), vous pouvez tirer parti de l'authentification avancée. des modèles 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 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 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 permettant à votre plan de données d'autoriser ou de 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 du service appelé 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.

Attention :Si vous configurez des règles DENY avec des attributs de requête tels que des hôtes, des ports et d'autres correspondances d'en-tête, nous recommandons vivement que les règles refusent tout le trafic. Certaines requêtes peuvent être autorisées de manière incorrecte. Par exemple, si vous configurez une règle DENY qui refuse tout le trafic avec host: service-test, un pirate informatique disposant d'un accès direct à votre backend peut envoyer une requête avec service-test:80. Comme cela ne correspond pas à service-test, la requête est incorrectement autorisée et le backend la diffuse.

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 clients, les règles TLS du 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.

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 est compatible avec une autorité de certification gérée, CA Service. 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. Vous associez les règles TLS du serveur à 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. Vous associez des stratégies d'autorisation à une ressource de stratégie de point de terminaison.

Une règle de stratégie d'autorisation se compose des composants suivants:

• from: spécifie l'identité du client autorisé par la règle. L'identité peut être dérivée d'un certificat client dans une connexion TLS mutuelle, ou il peut s'agir de l'identité ambiante associée à la VM cliente, par exemple à partir d'un compte de service ou d'un tag sécurisé.
• to: spécifie les opérations autorisées par la règle, telles que les URL auxquelles il est possible d'accéder ou les méthodes HTTP autorisées.
• when: vous permet de définir des contraintes supplémentaires à respecter. Vous pouvez utiliser des expressions CEL (Common Expression Language) pour définir les contraintes.
• action: spécifie l'action de la règle. Il peut être défini sur ALLOW, DENY ou CUSTOM.

Important :Cloud Service Mesh n'est pas encore compatible avec les règles CUSTOM.

Limites

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

Lors de l'évaluation d'une requête, une stratégie d'autorisation effectue l'une des actions suivantes:

• ALLOW: accorde l'accès à la ressource demandée si la requête correspond aux règles définies dans la stratégie d'autorisation. La stratégie d'autorisation bloque l'accès à la ressource demandée si la requête ne correspond à aucune règle définie dans la stratégie d'autorisation. Une requête est refusée si elle ne correspond pas à une règle ALLOW, même si d'autres règles l'autorisent.

• DENY: bloque l'accès à la ressource si une requête correspond à l'une des règles spécifiées dans une stratégie DENY. La stratégie d'autorisation accorde l'accès à la ressource demandée si la requête ne correspond à aucune règle définie dans la stratégie d'autorisation. Une requête est refusée si elle correspond à une règle DENY, même si d'autres règles l'autorisent.

• CUSTOM (non compatible avec Cloud Service Mesh): permet l'intégration à des systèmes d'autorisation externes pour les décisions d'autorisation complexes. Les actions CUSTOM sont utilisées pour les règles qui utilisent des extensions de service pour les décisions d'autorisation.

  Remarque :Vous ne pouvez définir qu'une seule stratégie d'autorisation avec l'action CUSTOM pour une règle de transfert ou une passerelle donnée.

Ordre d'évaluation des règles d'autorisation

Lorsque plusieurs règles d'autorisation sont associées à une même ressource, elles sont évaluées dans l'ordre suivant pour déterminer si une requête est autorisée ou refusée.

1. Règles avec des actions CUSTOM: si la règle CUSTOM refuse la requête, celle-ci est immédiatement rejetée. Les règles DENY ou ALLOW ne sont pas évaluées, même si elles sont configurées.

2. Règles avec actions DENY: si des règles DENY correspondent à la requête, celle-ci est refusée. Aucune règle ALLOW n'est évaluée, même si certaines sont configurées.

3. Règles avec des actions ALLOW: s'il n'existe aucune règle ALLOW ou si une règle ALLOW correspond à la requête, la requête est autorisée. Toutefois, si aucune règle ALLOW ne correspond à la requête, celle-ci est refusée.

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.

Quotas AuthzPolicy

• Vous êtes limité à cinq règles d'autorisation par passerelle.
• Vous êtes limité à 20 ressources AuthzPolicy par projet.
• Un seul objet AuthzPolicy peut pointer vers jusqu'à 100 gateways.

Étape suivante

• Pour en savoir plus sur les options de configuration, consultez la section Cas d'utilisation de la sécurité du service Cloud Service Mesh.
• Pour en savoir plus sur les stratégies d'autorisation, consultez la section Présentation des stratégies d'autorisation .
• Pour configurer la sécurité du service avec des proxys Envoy, consultez la section Configurer la sécurité du service Cloud Service Mesh avec Envoy.
• Pour configurer la sécurité du service avec des applications gRPC sans proxy, consultez la section Configurer la sécurité du service Cloud Service Mesh avec des applications gRPC sans proxy.