View a markdown version of this page

Protocole TLS (Transport Layer Security) - AWS App Mesh
Exigences du certificatCertificats d'authentification TLSComment App Mesh configure les envoyés pour négocier le protocole TLSVérifier le chiffrementRenouvellement des certificatsConfigurez les charges de travail Amazon ECS pour utiliser l'authentification TLS avec AWS App MeshConfigurez les charges de travail Kubernetes pour utiliser l'authentification TLS avec 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.

Protocole TLS (Transport Layer Security)

Important

Avis de fin de support : le 30 septembre 2026, AWS le support pour 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 Migration depuis Amazon ECS Service Connect AWS App Mesh vers Amazon ECS.

Dans App Mesh, le protocole TLS (Transport Layer Security) chiffre les communications entre les proxys Envoy déployés sur les ressources de calcul qui sont représentées dans App Mesh par des points de terminaison maillés, tels que et. Nœuds virtuels Passerelles virtuelles Le proxy négocie et met fin au protocole TLS. Lorsque le proxy est déployé avec une application, le code de votre application n'est pas responsable de la négociation d'une session TLS. Le proxy négocie le protocole TLS pour le compte de votre application.

App Mesh vous permet de fournir le certificat TLS au proxy de la manière suivante :

  • Un certificat privé de AWS Certificate Manager (ACM) qui est émis par un Autorité de certification privée AWS (CA privée AWS).

  • Un certificat stocké sur le système de fichiers local d'un nœud virtuel qui est émis par votre propre autorité de certification (CA)

  • Certificat fourni par un point de terminaison Secrets Discovery Service (SDS) via un socket de domaine Unix local.

Autorisation Envoy Proxydoit être activé pour le proxy Envoy déployé représenté par un point de terminaison maillé. Lorsque vous activez l'autorisation du proxy, nous vous recommandons de limiter l'accès au seul point de terminaison maillé pour lequel vous activez le chiffrement.

Exigences du certificat

L'un des noms alternatifs du sujet (SAN) du certificat doit répondre à des critères spécifiques, en fonction de la manière dont le service réel représenté par un point de terminaison maillé est découvert.

  • DNS  : l'un des certificats SAN doit correspondre à la valeur fournie dans les paramètres de découverte du service DNS. Pour une application portant le nom de découverte de servicesmesh-endpoint.apps.local, vous pouvez créer un certificat correspondant à ce nom ou un certificat avec le caractère générique*.apps.local.

  • AWS Cloud Map— L'un des certificats SAN doit correspondre à la valeur fournie dans les paramètres de découverte des AWS Cloud Map services à l'aide du formatservice-name.namespace-name. Pour une application dotée des AWS Cloud Map paramètres de découverte de services de ServiceName mesh-endpoint et de NameSpaceNameapps.local, vous pouvez créer un certificat correspondant au nom mesh-endpoint.apps.local ou un certificat avec le caractère générique *.apps.local.

Pour les deux mécanismes de découverte, si aucun des certificats SAN ne correspond aux paramètres de découverte du service DNS, la connexion entre Envoys échoue et le message d'erreur suivant est affiché par le client Envoy. 

TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED

Certificats d'authentification TLS

App Mesh prend en charge plusieurs sources de certificats lors de l'utilisation de l'authentification TLS.

CA privée AWS

Le certificat doit être stocké dans ACM dans la même région et dans le même AWS compte que le point de terminaison du maillage qui utilisera le certificat. Le certificat de l'autorité de certification n'a pas besoin de se trouver dans le même AWS compte, mais il doit tout de même se trouver dans la même région que le point de terminaison du maillage. Si vous n'en avez pas Autorité de certification privée AWS, vous devez en créer un avant de pouvoir lui demander un certificat. Pour plus d'informations sur la demande d'un certificat auprès d'un CA privée AWS fournisseur existant utilisant ACM, voir Demander un certificat privé. Le certificat ne peut pas être un certificat public.

Les autorités de certification privées que vous utilisez pour les politiques des clients TLS doivent être des autorités de certification utilisateur root.

Pour configurer un nœud virtuel avec des certificats et des autorités de certification provenant de CA privée AWS, le principal (tel qu'un utilisateur ou un rôle) que vous utilisez pour appeler App Mesh doit disposer des autorisations IAM suivantes :

  • Pour tous les certificats que vous ajoutez à la configuration TLS d'un écouteur, le principal doit disposer de l'acm:DescribeCertificateautorisation.

  • Pour toutes les autorités de certification configurées selon une politique client TLS, le principal doit disposer de l'acm-pca:DescribeCertificateAuthorityautorisation.

Important

Le partage de CA avec d'autres comptes peut conférer à ces comptes des privilèges imprévus au CA. Nous vous recommandons d'utiliser des politiques basées sur les ressources pour restreindre l'accès aux seuls comptes acm-pca:DescribeCertificateAuthority et acm-pca:GetCertificateAuthorityCertificate aux comptes qui n'ont pas besoin d'émettre de certificats auprès de l'autorité de certification.

Vous pouvez ajouter ces autorisations à une stratégie IAM existante associée à un principal ou créer un nouveau principal et une nouvelle stratégie et associer la politique au principal. Pour plus d'informations, consultez les sections Modification des politiques IAM, Création de politiques IAM et Ajout d'autorisations d'identité IAM.

Note

Vous payez une redevance mensuelle pour le fonctionnement de chacun d'eux CA privée AWS jusqu'à ce que vous le supprimiez. Vous payez également les certificats privés que vous émettez chaque mois et les certificats privés que vous exportez. Pour plus d’informations, consultez Tarification d’AWS Certificate Manager.

Lorsque vous activez l'autorisation proxy pour le proxy Envoy que représente un point de terminaison maillé, le rôle IAM que vous utilisez doit être doté des autorisations IAM suivantes :

  • Pour tous les certificats configurés sur l'écouteur d'un nœud virtuel, le rôle doit disposer de l'acm:ExportCertificateautorisation requise.

  • Pour toutes les autorités de certification configurées selon une politique client TLS, le rôle doit disposer de l'acm-pca:GetCertificateAuthorityCertificateautorisation requise.

Système de fichiers

Vous pouvez distribuer des certificats à Envoy à l'aide du système de fichiers. Vous pouvez le faire en rendant la chaîne de certificats et la clé privée correspondante disponibles sur le chemin du fichier. De cette façon, ces ressources sont accessibles depuis le proxy du sidecar Envoy.

Service de découverte secrète d'Envoy (SDS)

Envoy récupère des secrets tels que des certificats TLS à partir d'un point de terminaison spécifique via le protocole Secrets Discovery. Pour plus d'informations sur ce protocole, consultez la documentation https://www.envoyproxy.io/docs/envoy/latest/configuration/security/secret SDS d'Envoy.

App Mesh configure le proxy Envoy pour qu'il utilise un socket de domaine Unix local au proxy pour servir de point de terminaison du Secret Discovery Service (SDS) lorsque le SDS sert de source pour vos certificats et vos chaînes de certificats. Vous pouvez configurer le chemin vers ce point de terminaison à l'aide de la variable d'APPMESH_SDS_SOCKET_PATHenvironnement.

Important

Le service Local Secrets Discovery utilisant Unix Domain Socket est pris en charge sur les versions 1.15.1.0 et ultérieures du proxy App Mesh Envoy.

App Mesh prend en charge le protocole SDS V2 utilisant gRPC.

Intégration à l'environnement d'exécution SPIFFE (SPIRE)

Vous pouvez utiliser n'importe quelle implémentation annexe de l'API SDS, y compris les chaînes d'outils existantes comme SPIFFE Runtime Environment (SPIRE). SPIRE est conçu pour permettre le déploiement d'une authentification TLS mutuelle entre plusieurs charges de travail dans des systèmes distribués. Il atteste l'identité des charges de travail au moment de l'exécution. SPIRE fournit également des clés et des certificats spécifiques à la charge de travail, de courte durée et à rotation automatique directement vers les charges de travail.

Vous devez configurer l'agent SPIRE en tant que fournisseur de SDS pour Envoy. Autorisez-le à fournir directement à Envoy le matériel clé dont il a besoin pour fournir une authentification TLS mutuelle. Exécutez les agents SPIRE dans des sidecars à côté des proxys Envoy. L'agent se charge de régénérer les clés et les certificats éphémères selon les besoins. L'agent atteste Envoy et détermine les identités de service et les certificats CA qu'il doit mettre à la disposition d'Envoy lorsqu'Envoy se connecte au serveur SDS exposé par l'agent SPIRE.

Au cours de ce processus, les identités de service et les certificats CA font l'objet d'une rotation, et les mises à jour sont retransmises à Envoy. Envoy les applique immédiatement aux nouvelles connexions, sans interruption ni temps d'arrêt et sans que les clés privées n'entrent en contact avec le système de fichiers.

Comment App Mesh configure les envoyés pour négocier le protocole TLS

App Mesh utilise la configuration du point de terminaison maillé du client et du serveur pour déterminer comment configurer la communication entre les envoyés dans un maillage.

Avec les politiques relatives aux clients

Lorsqu'une politique client impose l'utilisation de TLS et que l'un des ports de la politique client correspond au port de la politique du serveur, la politique client est utilisée pour configurer le contexte de validation TLS du client. Par exemple, si la politique client d'une passerelle virtuelle correspond à la politique de serveur d'un nœud virtuel, une négociation TLS sera tentée entre les proxys à l'aide des paramètres définis dans la politique client de la passerelle virtuelle. Si la politique client ne correspond pas au port de la politique du serveur, le TLS entre les proxys peut être négocié ou non, en fonction des paramètres TLS de la politique du serveur.

Sans politiques relatives aux clients

Si le client n'a pas configuré de politique client ou si celle-ci ne correspond pas au port du serveur, App Mesh utilisera le serveur pour déterminer s'il convient ou non de négocier le protocole TLS avec le client, et comment. Par exemple, si une passerelle virtuelle n'a pas spécifié de politique client et qu'un nœud virtuel n'a pas configuré de terminaison TLS, le TLS ne sera pas négocié entre les proxys. Si un client n'a pas spécifié de politique client correspondante et qu'un serveur a été configuré avec les modes TLS STRICT ouPERMISSIVE, les proxys seront configurés pour négocier le TLS. Selon la manière dont les certificats ont été fournis pour la résiliation du protocole TLS, le comportement supplémentaire suivant s'applique.

  • ACM-managed Certificats TLS  : lorsqu'un serveur a configuré la terminaison TLS à l'aide d'un ACM-managed certificat, App Mesh configure automatiquement les clients pour négocier le protocole TLS et valider le certificat par rapport à l'autorité de certification utilisateur racine à laquelle le certificat est lié.

  • File-based Certificats TLS  : lorsqu'un serveur a configuré la terminaison TLS à l'aide d'un certificat provenant du système de fichiers local du proxy, App Mesh configure automatiquement un client pour négocier le protocole TLS, mais le certificat du serveur n'est pas validé.

Noms alternatifs du sujet

Vous pouvez éventuellement spécifier une liste de noms alternatifs de sujet (SAN) auxquels vous pouvez faire confiance. Les SAN doivent être au format FQDN ou URI. Si des SAN sont fournis, Envoy vérifie que le nom alternatif du sujet du certificat présenté correspond à l'un des noms de cette liste.

Si vous ne spécifiez pas de SAN sur le point de terminaison du maillage terminal, le proxy Envoy pour ce nœud ne vérifie pas le SAN sur un certificat client homologue. Si vous ne spécifiez pas de SAN sur le point de terminaison du maillage d'origine, le SAN du certificat fourni par le point de terminaison terminal doit correspondre à la configuration de découverte de service du point de terminaison du maillage.

Pour plus d'informations, consultez App Mesh TLS : Exigences relatives aux certificats.

Important

Vous ne pouvez utiliser des SAN génériques que si la politique client pour TLS est définie sur. not enforced Si la politique client pour le nœud virtuel client ou la passerelle virtuelle est configurée pour appliquer le protocole TLS, elle ne peut pas accepter un SAN générique.

Vérifier le chiffrement

Une fois que vous avez activé le protocole TLS, vous pouvez interroger le proxy Envoy pour confirmer que la communication est cryptée. Le proxy Envoy émet des statistiques sur les ressources qui peuvent vous aider à déterminer si votre communication TLS fonctionne correctement. Par exemple, le proxy Envoy enregistre des statistiques sur le nombre de handshakes TLS réussis qu'il a négociés pour un point de terminaison de maillage spécifié. Déterminez le nombre de prises de contact TLS réussies pour un point de terminaison maillé nommé à l'my-mesh-endpointaide de la commande suivante.

curl -s 'http://my-mesh-endpoint.apps.local:9901/stats' | grep ssl.handshake

Dans l'exemple de sortie renvoyé suivant, il y a eu trois poignées de main pour le point de terminaison maillé, de sorte que la communication est cryptée.

listener.0.0.0.0_15000.ssl.handshake: 3

Le proxy Envoy émet également des statistiques lorsque la négociation TLS échoue. Déterminez s'il y a eu des erreurs TLS pour le point de terminaison du maillage.

curl -s 'http://my-mesh-endpoint.apps.local:9901/stats' | grep -e "ssl.*\(fail\|error\)"

Dans l'exemple de sortie renvoyé, il n'y avait aucune erreur pour plusieurs statistiques. La négociation TLS a donc réussi.

listener.0.0.0.0_15000.ssl.connection_error: 0
listener.0.0.0.0_15000.ssl.fail_verify_cert_hash: 0
listener.0.0.0.0_15000.ssl.fail_verify_error: 0
listener.0.0.0.0_15000.ssl.fail_verify_no_cert: 0
listener.0.0.0.0_15000.ssl.ssl.fail_verify_san: 0

Pour plus d'informations sur les statistiques Envoy TLS, consultez Envoy Listener Statistics.

Renouvellement des certificats

CA privée AWS

Lorsque vous renouvelez un certificat auprès d'ACM, le certificat renouvelé est automatiquement distribué à vos proxys connectés dans les 35 minutes suivant la fin du renouvellement. Nous vous recommandons d'utiliser le renouvellement géré pour renouveler automatiquement les certificats approchant de la fin de leur période de validité. Pour plus d'informations, consultez la section Renouvellement géré des Amazon-Issued certificats ACM dans le Guide de l' AWS Certificate Manager utilisateur.

Votre propre certificat

Lorsque vous utilisez un certificat provenant du système de fichiers local, Envoy ne recharge pas automatiquement le certificat en cas de modification. Vous pouvez soit redémarrer, soit redéployer le processus Envoy pour charger un nouveau certificat. Vous pouvez également placer un certificat plus récent dans un autre chemin de fichier et mettre à jour la configuration du nœud virtuel ou de la passerelle avec ce chemin de fichier.

Configurez les charges de travail Amazon ECS pour utiliser l'authentification TLS avec AWS App Mesh

Vous pouvez configurer votre maillage pour utiliser l'authentification TLS. Assurez-vous que les certificats sont disponibles pour les sidecars proxy Envoy que vous ajoutez à vos charges de travail. Vous pouvez associer un volume EBS ou EFS à votre side-car Envoy, ou vous pouvez stocker et récupérer des certificats depuis AWS Secrets Manager.

  • Si vous utilisez la distribution de certificats basée sur des fichiers, associez un volume EBS ou EFS à votre side-car Envoy. Assurez-vous que le chemin d'accès au certificat et à la clé privée correspond à celui qui est configuré dans AWS App Mesh.

  • Si vous utilisez SDS-based la distribution, ajoutez un side-car qui implémente l'API SDS d'Envoy avec accès au certificat.

Note

SPIRE n'est pas pris en charge sur Amazon ECS.

Configurez les charges de travail Kubernetes pour utiliser l'authentification TLS avec AWS App Mesh

Vous pouvez configurer le AWS App Mesh Controller pour Kubernetes afin d'activer l'authentification TLS pour les backends et les auditeurs des services de nœud virtuel et de passerelle virtuelle. Assurez-vous que les certificats sont disponibles pour les sidecars proxy Envoy que vous ajoutez à vos charges de travail. Vous pouvez voir un exemple pour chaque type de distribution dans la section de présentation de l'authentification TLS mutuelle.

  • Si vous utilisez la distribution de certificats basée sur des fichiers, associez un volume EBS ou EFS à votre side-car Envoy. Assurez-vous que le chemin d'accès au certificat et à la clé privée correspond à celui configuré dans le contrôleur. Vous pouvez également utiliser un secret Kubernetes monté sur le système de fichiers.

  • Si vous utilisez SDS-based la distribution, vous devez configurer un fournisseur de SDS local de nœud qui implémente l'API SDS d'Envoy. Envoy y parviendra via UDS. Pour activer la prise en charge mTLS basée sur le SDS dans le AppMesh contrôleur EKS, définissez l'enable-sdsindicateur sur true et fournissez le chemin UDS du fournisseur SDS local au contrôleur via l'indicateur. sds-uds-path Si vous utilisez helm, vous les définissez dans le cadre de l'installation de votre contrôleur : 

    --set sds.enabled=true
Note

Vous ne pourrez pas utiliser SPIRE pour distribuer vos certificats si vous utilisez Amazon Elastic Kubernetes Service (Amazon EKS) en mode Fargate.