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.
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
Dans App Mesh, Transport Layer Security (TLS) chiffre les communications entre les proxys Envoy déployés sur les ressources informatiques représentées dans App Mesh par des points de terminaison du maillage, 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) émis par un AWS Private Certificate Authority (AWS Private CA).
-
Certificat stocké sur le système de fichiers local d'un nœud virtuel émis par votre propre autorité de certification (CA)
-
Certificat fourni par un point de terminaison SDS (Secrets Discovery Service) 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 restreindre l'accès uniquement au point de terminaison maillé pour lequel vous activez le chiffrement.
Exigences du certificat
L'un des noms alternatifs du sujet (SANs) figurant sur le 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 du maillage est découvert.
-
DNS — L'un des certificats SANs doit correspondre à la valeur fournie dans les paramètres de découverte du service DNS. Pour une application portant le nom Service Discovery
mesh-endpoint.apps.local*..apps.local -
AWS Cloud Map— L'un des certificats SANs doit correspondre à la valeur fournie dans les paramètres de découverte du AWS Cloud Map service à l'aide du format
service-name.namespace-namemesh-endpointapps.localmesh-endpoint.apps.local*.apps.local.
Pour les deux mécanismes de découverte, si aucun certificat ne SANs correspond aux paramètres de découverte du service DNS, la connexion entre Envoys échoue avec le message d'erreur suivant, comme indiqué par le client Envoy.
TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILEDCertificats d'authentification TLS
App Mesh prend en charge plusieurs sources de certificats lors de l'utilisation de l'authentification TLS.
- AWS Private CA
-
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 ne doit pas nécessairement 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 utilisateur AWS Private CA ACM existant, consultez la section Demander un certificat privé. Le certificat ne peut pas être un certificat public.
Le privé CAs que vous utilisez pour les politiques du client TLS doit être un utilisateur CAs root.
Pour configurer un nœud virtuel avec des certificats et CAs depuis AWS Private CA, 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 toute politique CAs configurée sur un client TLS, le principal doit avoir l'
acm-pca:DescribeCertificateAuthorityautorisation.
Important
Le partage CAs avec d'autres comptes peut conférer à ces comptes des privilèges involontaires à l'autorité de certification. Nous recommandons d'utiliser des politiques basées sur les ressources afin de restreindre l'accès aux seuls
acm-pca:DescribeCertificateAuthoritycomptes qui n'ont pas besoin d'émettre de certificats auprès de l'autorité de certification.acm-pca:GetCertificateAuthorityCertificateVous pouvez ajouter ces autorisations à une stratégie IAM existante attachée à un principal ou créer un nouveau principal et une nouvelle stratégie et associer la stratégie 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 des frais mensuels pour le fonctionnement de chacune d'elles AWS Private CA jusqu'à ce que vous les supprimiez. Vous payez également pour les certificats privés que vous émettez chaque mois et pour les certificats privés que vous exportez. Pour plus d'informations, consultez Tarification AWS Certificate Manager
. Lorsque vous activez l'autorisation de proxy pour le proxy Envoy représenté par un point de terminaison maillé, les autorisations IAM suivantes doivent être attribuées au rôle IAM que vous utilisez :
-
Pour tous les certificats configurés sur l'écouteur d'un nœud virtuel, le rôle doit disposer de l'
acm:ExportCertificateautorisation. -
Pour toute politique de client CAs configurée sur une base TLS, le rôle doit disposer de l'
acm-pca:GetCertificateAuthorityCertificateautorisation.
-
- 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 (SDS) d'Envoy
-
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 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 chaînes de certificats. Vous pouvez configurer le chemin d'accès à ce point de terminaison à l'aide de la variable d'
APPMESH_SDS_SOCKET_PATHenvironnement.Important
Le service Local Secrets Discovery utilisant un socket de domaine Unix 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 V2 SDS à l'aide de gRPC.
- Intégration à l'environnement d'exécution SPIFFE (SPIRE)
-
Vous pouvez utiliser n'importe quelle implémentation parallèle de l'API SDS, y compris les chaînes d'outils existantes telles que SPIFFE Runtime Environment (SPIRE
). SPIRE est conçu pour permettre le déploiement de l'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 aux charges de travail, de courte durée et en rotation automatique directement vers les charges de travail. Vous devez configurer l'agent SPIRE en tant que fournisseur SDS pour Envoy. Permettez-lui de 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 situés à 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 renvoyées à Envoy. Envoy les applique immédiatement aux nouvelles connexions, sans interruption ni interruption et sans que les clés privées ne touchent le système de fichiers.
Comment App Mesh configure Envoys pour négocier le TLS
App Mesh utilise la configuration des points de terminaison du maillage du client et du serveur pour déterminer comment configurer la communication entre les envoyés dans un maillage.
- Avec les politiques du client
-
Lorsqu'une politique client impose l'utilisation du protocole TLS et que l'un des ports de la politique client correspond au port de la stratégie du serveur, la stratégie 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 en utilisant les paramètres définis dans la politique client de la passerelle virtuelle. Si la politique du client ne correspond pas au port de la politique du serveur, le protocole 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é la terminaison TLS, le protocole TLS ne sera pas négocié entre les proxys. Si aucun client n'a spécifié de politique client correspondante et qu'un serveur a été configuré avec les modes
STRICTTLSPERMISSIVE, les proxys seront configurés pour négocier le protocole TLS. En fonction de la manière dont les certificats ont été fournis pour la terminaison du protocole TLS, le comportement supplémentaire suivant s'applique.-
Certificats TLS gérés par ACM — Lorsqu'un serveur a configuré la terminaison TLS à l'aide d'un certificat géré par ACM, App Mesh configure automatiquement les clients pour négocier le protocole TLS et valider le certificat auprès de l'autorité de certification de l'utilisateur racine à laquelle le certificat est lié.
-
Certificats TLS basés sur des fichiers : lorsqu'un serveur a configuré la terminaison TLS à l'aide d'un certificat issu 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 sujets (SANs) auxquels vous pouvez faire confiance. SANs doit être au format FQDN ou URI. S' SANs ils 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 SANs le point de terminaison du maillage, le proxy Envoy pour ce nœud ne vérifie pas le SAN sur un certificat client homologue. Si vous ne spécifiez pas SANs le point de terminaison d'origine, le SAN du certificat fourni par le point de terminaison doit correspondre à la configuration du service de découverte du point de terminaison du point de terminaison.
Pour plus d'informations, consultez App Mesh TLS : Exigences relatives aux certificats.
Important
Vous ne pouvez utiliser un caractère générique que SANs si la politique client pour TLS est définie sur.
not enforcedSi la politique client du nœud virtuel ou de la passerelle virtuelle du client est configurée pour appliquer le protocole TLS, il 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 les communications sont cryptées. 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 handshakes TLS réussis pour un point de terminaison de maillage nommé à l'my-mesh-endpoint
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 du maillage. La communication est donc cryptée.
listener.0.0.0.0_15000.ssl.handshake: 3Le 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 renvoyé, aucune erreur n'a été détectée 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: 0Pour plus d'informations sur les statistiques Envoy TLS, consultez Envoy Listener
Renouvellement des certificats
AWS Private CA
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 à l'approche de la fin de leur période de validité. Pour plus d'informations, consultez la section Gestion du renouvellement des certificats émis par Amazon par ACM dans le guide de l' AWS Certificate Manager utilisateur.
Votre propre certificat
Lorsque vous utilisez un certificat issu du système de fichiers local, Envoy ne le recharge pas automatiquement lorsqu'il est modifié. Vous pouvez redémarrer ou redéployer le processus Envoy pour charger un nouveau certificat. Vous pouvez également placer un nouveau certificat sur un chemin de fichier différent et mettre à jour la configuration du nœud virtuel ou de la passerelle avec ce chemin de fichier.
Configurer 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 sidecar Envoy, ou vous pouvez stocker et récupérer des certificats depuis Secrets Manager AWS .
-
Si vous utilisez la distribution de certificats basée sur des fichiers, attachez un volume EBS ou EFS à votre sidecar Envoy. Assurez-vous que le chemin d'accès au certificat et à la clé privée correspond à celui configuré dans AWS App Mesh.
-
Si vous utilisez une distribution basée sur le SDS, ajoutez un sidecar qui implémente l'API SDS d'Envoy avec accès au certificat.
Note
SPIRE n'est pas pris en charge sur Amazon ECS.
Configurer les charges de travail Kubernetes pour utiliser l'authentification TLS avec AWS App Mesh
Vous pouvez configurer le AWS App Mesh Controller for Kubernetes pour activer l'authentification TLS pour les backends et les écouteurs des services de nœuds virtuels et de passerelle virtuelle. Assurez-vous que les certificats sont disponibles pour les sidecars proxy Envoy que vous ajoutez à vos charges de travail. Vous trouverez 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, attachez un volume EBS ou EFS à votre sidecar 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 une distribution basée sur SDS, vous devez configurer un fournisseur SDS local de nœuds qui implémente l'API SDS d'Envoy. Envoy l'atteindra via UDS. Pour activer la prise en charge des MTLs basés sur le SDS dans le AppMesh contrôleur EKS, définissez l'
enable-sdsindicateur surtrueet fournissez le chemin UDS du fournisseur SDS local au contrôleur via l'indicateur.sds-uds-pathSi vous utilisez helm, vous devez les configurer 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.
