TLSAuthentification 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.

TLSAuthentification mutuelle

Important

Avis de fin de support : le 30 septembre 2026, AWS le support de. AWS App Mesh Après le 30 septembre 2026, vous ne pourrez plus accéder à la AWS App Mesh console ni aux AWS App Mesh ressources. Pour plus d'informations, consultez ce billet de blog intitulé Migration from AWS App Mesh to Amazon ECS Service Connect.

L'authentification mutuelle TLS (Transport Layer Security) est un composant facultatif TLS qui offre une authentification bidirectionnelle entre pairs. TLSL'authentification mutuelle ajoute une couche de sécurité 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 TLS l'authentification mutuelle pour tous les protocoles pris en charge par AWS App Mesh. Ils sontTCP, HTTP /1.1, HTTP /2, g. RPC

Note

À l'aide d'App Mesh, vous pouvez configurer TLS l'authentification 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 TLS d'authentification mutuelle

AWS App Mesh prend en charge deux sources de certificats possibles pour TLS l'authentification mutuelle. Les certificats client dans une politique TLS client et la validation du serveur dans une TLS configuration 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'App MeshAPI.

  • Envoy's Secret Discovery Service (SDS) : des Bring-your-own sidecars qui implémentent SDS et autorisent l'envoi de certificats à Envoy. Ils incluent l'environnement SPIFFE d'exécution (SPIRE).

Important

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

Configurer les points de terminaison du maillage

Configurez TLS l'authentification 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 validation de la TLS résiliation et de l'TLSorigine.

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

Les certificats côté serveur sont configurés dans les écouteurs Virtual Node (TLSterminaison), 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 TLS l'authentification 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 résiliation. 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 (CAs) que les certificats côté serveur utilisent sur l'écouteur Virtual Gateway pour l'origine. TLS

Migrer les services vers l'TLSauthentification mutuelle

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

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

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

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

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

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

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

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

Vérification de l'TLSauthentification mutuelle

Vous pouvez vous référer à la documentation Transport Layer Security : Verify encryption pour savoir exactement comment Envoy émet les statistiques TLS associées. Pour TLS l'authentification 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 TLS les connexions réussies aboutissant au nœud virtuel provenaient 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 noms SANs approuvés par le client.

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

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