protocole TLS (Transport Layer Security)

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 Passerelle 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 au nom 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.

Autormation du proxy Envoydoit ê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 de sujet (SAN) 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 de maillage est découvert.

• DNS — L'un des réseaux SAN de certificats doit correspondre à la valeur spécifiée dans les paramètres de découverte du service DNS. Pour une application portant le nom Service Discoverymesh-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 SAN de certificats 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 dont les paramètres de découverte de AWS Cloud Map service sont ServiceName mesh-endpoint et 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 SAN de certificats ne correspond aux paramètres de découverte du service DNS, la connexion entre Envoys échoue avec le message d'erreur suivant, tel qu'il est indiqué 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.

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.

Les autorités de certification privées que vous utilisez pour les politiques du client 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 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 toutes les autorités de certification configurées selon une politique client TLS, le principal doit avoir l'acm-pca:DescribeCertificateAuthorityautorisation.

Important

Le partage d'une autorité de certification 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:DescribeCertificateAuthority comptes qui n'ont pas besoin d'émettre de certificats auprès de l'autorité de certification. acm-pca:GetCertificateAuthorityCertificate

Vous 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 d’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 toutes les autorités de certification configurées selon une politique client 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 la politique client 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 STRICT TLSPERMISSIVE, 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 (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 à caractères génériques que si la politique client pour TLS est définie sur. not enforced Si 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-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 du maillage. La communication est donc 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 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: 0

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

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 USD. Pour activer la prise en charge des MTLs basés 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 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.