Authentification TLS mutuelle - AWS App Mesh

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Authentification TLS mutuelle

L'authentification mutuelle TLS (Transport Layer Security) est un composant facultatif du protocole TLS qui offre une authentification bidirectionnelle entre pairs. L'authentification TLS mutuelle ajoute une couche de sécurité par rapport au protocole TLS et permet à vos services de vérifier le client qui établit la connexion.

Dans la relation client-serveur, le client fournit également un certificat X.509 pendant le processus de négociation de session. Le serveur utilise ce certificat pour identifier et authentifier le client. Ce processus permet de vérifier si le certificat est émis par une autorité de certification (CA) fiable et s'il s'agit d'un certificat valide. Il utilise également le nom alternatif du sujet (SAN) sur le certificat pour identifier le client.

Vous pouvez activer l'authentification TLS mutuelle pour tous les protocoles pris en charge par AWS App Mesh. Il s'agit de TCP, HTTP/1.1, HTTP/2, gRPC.

Note

À l'aide d'App Mesh, vous pouvez configurer l'authentification TLS mutuelle pour les communications entre les proxys Envoy depuis vos services. Cependant, les communications entre vos applications et les proxys Envoy ne sont pas cryptées.

Certificats d'authentification TLS mutuels

AWS App Mesh prend en charge deux sources de certificats possibles pour l'authentification TLS mutuelle. Les certificats client dans une politique client TLS et la validation du serveur dans une configuration TLS d'écouteur peuvent provenir de :

  • Système de fichiers : certificats provenant du système de fichiers local du proxy Envoy en cours d'exécution. Pour distribuer des certificats à Envoy, vous devez fournir des chemins de fichiers pour la chaîne de certificats et une clé privée vers l'API App Mesh.

  • Service de découverte secrète (SDS) d'Envoy : des ring-your-own sidecars B qui implémentent le SDS et autorisent l'envoi de certificats à Envoy. Ils incluent l'environnement d'exécution SPIFFE (SPIRE).

Important

App Mesh ne stocke pas les certificats ou les clés privées utilisés pour l'authentification TLS mutuelle. Au lieu de cela, Envoy les stocke en mémoire.

Configurer les points de terminaison du maillage

Configurez l'authentification TLS mutuelle pour vos points de terminaison maillés, tels que les nœuds virtuels ou les passerelles. Ces points de terminaison fournissent des certificats et spécifient des autorités fiables.

Pour ce faire, vous devez fournir des certificats X.509 à la fois pour le client et pour le serveur, et définir explicitement les certificats d'autorité de confiance dans le contexte de la validation de la terminaison et de l'origine du protocole TLS.

La confiance à l'intérieur d'un maillage

Les certificats côté serveur sont configurés dans les écouteurs Virtual Node (terminaison TLS), et les certificats côté client sont configurés dans les backends du service Virtual Nodes (origine TLS). Comme alternative à cette configuration, vous pouvez définir une politique client par défaut pour tous les backends de services d'un nœud virtuel, puis, si nécessaire, vous pouvez remplacer cette politique pour des backends spécifiques selon les besoins. Les passerelles virtuelles ne peuvent être configurées qu'avec une politique client par défaut qui s'applique à tous ses backends.

Vous pouvez configurer la confiance entre différents maillages en activant l'authentification TLS mutuelle pour le trafic entrant sur les passerelles virtuelles pour les deux maillages.

Confiance en dehors d'un maillage

Spécifiez les certificats côté serveur dans l'écouteur Virtual Gateway pour la terminaison TLS. Configurez le service externe qui communique avec votre passerelle virtuelle pour présenter les certificats côté client. Les certificats doivent être dérivés de l'une des mêmes autorités de certification (CA) que les certificats côté serveur utilisent sur l'écouteur Virtual Gateway pour la création du protocole TLS.

Migrer les services vers l'authentification TLS mutuelle

Suivez ces directives pour maintenir la connectivité lors de la migration de vos services existants dans App Mesh vers l'authentification TLS mutuelle.

Migration des services communiquant en texte brut
  1. Activer le PERMISSIVE mode pour la configuration TLS sur le point de terminaison du serveur. Ce mode permet au trafic en texte brut de se connecter au point de terminaison.

  2. Configurez l'authentification TLS mutuelle sur votre serveur, en spécifiant le certificat du serveur, la chaîne de confiance et éventuellement les SAN fiables.

  3. Vérifiez que la communication s'effectue via une connexion TLS.

  4. Configurez l'authentification TLS mutuelle sur vos clients, en spécifiant le certificat client, la chaîne de confiance et éventuellement les SAN fiables.

  5. STRICTMode d'activation pour la configuration TLS sur le serveur.

Migration des services communiquant via TLS
  1. Configurez les paramètres TLS mutuels sur vos clients, en spécifiant le certificat client et éventuellement les SAN fiables. Le certificat client n'est envoyé à son serveur principal qu'une fois que le serveur principal l'a demandé.

  2. Configurez les paramètres TLS mutuels sur votre serveur, en spécifiant la chaîne de confiance et éventuellement les SAN fiables. Pour cela, votre serveur demande un certificat client.

Vérification de l'authentification TLS mutuelle

Vous pouvez vous référer à la documentation Transport Layer Security : Verify encryption pour savoir exactement comment Envoy émet les statistiques relatives au TLS. Pour l'authentification TLS mutuelle, vous devez vérifier les statistiques suivantes :

  • ssl.handshake

  • ssl.no_certificate

  • ssl.fail_verify_no_cert

  • ssl.fail_verify_san

Les deux exemples de statistiques suivants montrent ensemble que les connexions TLS réussies aboutissant au nœud virtuel proviennent toutes d'un client qui a fourni un certificat.

listener.0.0.0.0_15000.ssl.handshake: 3
listener.0.0.0.0_15000.ssl.no_certificate: 0

L'exemple de statistique suivant montre que les connexions entre un nœud client virtuel (ou passerelle) et un nœud virtuel principal ont échoué. Le nom alternatif du sujet (SAN) présenté dans le certificat du serveur ne correspond à aucun des SAN approuvés par le client.

cluster.cds_egress_my-mesh_my-backend-node_http_9080.ssl.fail_verify_san: 5

Procédures pas à pas de l'authentification TLS mutuelle App Mesh