Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Transport Layer Security (TLS) **Wichtig** Hinweis zum Ende des Supports: Am 30. September 2026 AWS wird der Support für eingestellt. AWS App Mesh Nach dem 30. September 2026 werden Sie nicht mehr auf die AWS App Mesh Konsole oder die Ressourcen zugreifen können. AWS App Mesh Weitere Informationen finden Sie in diesem Blogbeitrag [ Migration von AWS App Mesh zu Amazon ECS Service Connect. ](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect) In App Mesh verschlüsselt Transport Layer Security (TLS) die Kommunikation zwischen den Envoy-Proxys, die auf Rechenressourcen bereitgestellt werden, die in App Mesh durch Mesh-Endpunkte wie und repräsentiert werden. [Virtuelle Knoten](virtual_nodes.md) [Virtuelle Gateways](virtual_gateways.md) Der Proxy handelt TLS aus und beendet es. Wenn der Proxy zusammen mit einer Anwendung bereitgestellt wird, ist Ihr Anwendungscode nicht für die Aushandlung einer TLS-Sitzung verantwortlich. Der Proxy handelt TLS im Namen Ihrer Anwendung aus. Mit App Mesh können Sie das TLS-Zertifikat auf folgende Weise für den Proxy bereitstellen: + Ein privates Zertifikat von AWS Certificate Manager (ACM), das von einem AWS Private Certificate Authority (AWS Private CA) ausgestellt wird. + Ein Zertifikat, das im lokalen Dateisystem eines virtuellen Knotens gespeichert ist und von Ihrer eigenen Zertifizierungsstelle (CA) ausgestellt wurde + Ein Zertifikat, das von einem Secrets Discovery Service (SDS) -Endpunkt über einen lokalen Unix-Domain-Socket bereitgestellt wird. [Envoy Proxy-Autorisierung](proxy-authorization.md)muss für den bereitgestellten Envoy-Proxy aktiviert werden, der durch einen Mesh-Endpunkt dargestellt wird. Wir empfehlen, bei der Aktivierung der Proxy-Autorisierung den Zugriff nur auf den Mesh-Endpunkt zu beschränken, für den Sie die Verschlüsselung aktivieren. ## Zertifikatanforderungen Einer der Subject Alternative Names (SANs) auf dem Zertifikat muss bestimmten Kriterien entsprechen, je nachdem, wie der eigentliche Dienst, der durch einen Mesh-Endpunkt repräsentiert wird, erkannt wird. + **DNS ** — Eines der Zertifikats-SANs muss dem in den DNS-Dienst-Discovery-Einstellungen angegebenen Wert entsprechen. Für eine Anwendung mit dem Service Discovery-Namen können Sie ein Zertifikat erstellen`{{mesh-endpoint.apps.local}}`, das diesem Namen entspricht, oder ein Zertifikat mit dem Platzhalter`*.{{apps.local}}`. + **AWS Cloud Map**— Eines der Zertifikats-SANs muss dem Wert entsprechen, der in den AWS Cloud Map Service Discovery-Einstellungen angegeben ist, und das Format verwenden`{{service-name.namespace-name}}`. Für eine Anwendung mit den AWS Cloud Map Service Discovery-Einstellungen von ServiceName `{{mesh-endpoint}}` und NamespaceName können Sie ein Zertifikat erstellen`{{apps.local}}`, das dem Namen entspricht`{{mesh-endpoint.apps.local}}`, oder ein Zertifikat mit dem Platzhalter `*.{{apps.local}}.` Bei beiden Discovery-Mechanismen gilt: Wenn keines der Zertifikats-SANs den DNS-Dienst-Discovery-Einstellungen entspricht, schlägt die Verbindung zwischen Envoys fehl und es wird die folgende Fehlermeldung angezeigt, die vom Client Envoy aus angezeigt wird. ``` TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED ``` ## TLS-Authentifizierungszertifikate App Mesh unterstützt mehrere Quellen für Zertifikate, wenn die TLS-Authentifizierung verwendet wird. **AWS Private CA** Das Zertifikat muss in ACM in derselben Region und demselben AWS Konto wie der Mesh-Endpunkt gespeichert werden, der das Zertifikat verwenden wird. Das Zertifikat der CA muss sich nicht im selben AWS Konto befinden, aber es muss sich trotzdem in derselben Region wie der Mesh-Endpunkt befinden. Wenn Sie kein Zertifikat haben AWS Private CA, müssen Sie eines [ erstellen, ](https://docs.aws.amazon.com/acm-pca/latest/userguide/PcaCreateCa.html) bevor Sie ein Zertifikat von diesem anfordern können. Weitere Informationen zum Anfordern eines Zertifikats von einem bereits AWS Private CA verwendeten ACM finden Sie unter [ Anfordern eines privaten Zertifikats](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-private.html). Das Zertifikat kann kein öffentliches Zertifikat sein. Die privaten Zertifizierungsstellen, die Sie für TLS-Client-Richtlinien verwenden, müssen Stammbenutzer-CAs sein. Um einen virtuellen Knoten mit Zertifikaten und CAs von zu konfigurieren AWS Private CA, muss der Principal (z. B. ein Benutzer oder eine Rolle), den Sie zum Aufrufen von App Mesh verwenden, über die folgenden IAM-Berechtigungen verfügen: + Für alle Zertifikate, die Sie der TLS-Konfiguration eines Listeners hinzufügen, muss der Prinzipal über die Berechtigung verfügen. `acm:DescribeCertificate` + Für alle Zertifizierungsstellen, die für eine TLS-Client-Richtlinie konfiguriert sind, muss der Prinzipal über die `acm-pca:DescribeCertificateAuthority` Berechtigung verfügen. Durch die gemeinsame Nutzung von Zertifizierungsstellen mit anderen Konten erhalten diese Konten möglicherweise unbeabsichtigte Rechte an die CA. Wir empfehlen, ressourcenbasierte Richtlinien zu verwenden, um den Zugriff nur `acm-pca:DescribeCertificateAuthority` auf Konten zu beschränken, die keine Zertifikate von der CA ausstellen müssen. `acm-pca:GetCertificateAuthorityCertificate` Sie können diese Berechtigungen zu einer vorhandenen IAM-Richtlinie hinzufügen, die einem Principal zugeordnet ist, oder Sie können einen neuen Principal und eine neue Richtlinie erstellen und die Policy dem Principal zuordnen. Weitere Informationen finden Sie unter [ Bearbeiten von IAM-Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html), [ Erstellen von IAM-Richtlinien ](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) und [ Hinzufügen von IAM-Identitätsberechtigungen. ](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console) Sie zahlen eine monatliche Gebühr für deren Betrieb, AWS Private CA bis Sie sie löschen. Sie zahlen auch für die privaten Zertifikate, die Sie jeden Monat ausstellen, und für private Zertifikate, die Sie exportieren. Weitere Informationen finden Sie unter [AWS Certificate Manager  – Preise](https://aws.amazon.com/certificate-manager/pricing/). Wenn Sie die [ Proxyautorisierung ](proxy-authorization.md) für den Envoy-Proxy aktivieren, den ein Mesh-Endpunkt darstellt, müssen der von Ihnen verwendeten IAM-Rolle die folgenden IAM-Berechtigungen zugewiesen werden: + Für alle Zertifikate, die auf dem Listener eines virtuellen Knotens konfiguriert sind, muss die Rolle über die entsprechende Berechtigung verfügen. `acm:ExportCertificate` + Für alle Zertifizierungsstellen, die für eine TLS-Client-Richtlinie konfiguriert sind, muss die Rolle über die `acm-pca:GetCertificateAuthorityCertificate` entsprechende Berechtigung verfügen. **Dateisystem** Sie können Zertifikate mithilfe des Dateisystems an Envoy verteilen. Sie können dies tun, indem Sie die Zertifikatskette und den entsprechenden privaten Schlüssel im Dateipfad verfügbar machen. Auf diese Weise sind diese Ressourcen vom Envoy-Sidecar-Proxy aus erreichbar. **Der Secret Discovery Service (SDS) des Gesandten** Envoy ruft mithilfe des Secrets Discovery-Protokolls Geheimnisse wie TLS-Zertifikate von einem bestimmten Endpunkt ab. Weitere Informationen zu diesem Protokoll finden Sie in der SDS-Dokumentation von [ Envoy. ](https://www.envoyproxy.io/docs/envoy/latest/configuration/security/secret) App Mesh konfiguriert den Envoy-Proxy so, dass er einen Unix-Domain-Socket verwendet, der sich lokal auf dem Proxy befindet und als Secret Discovery Service (SDS) -Endpunkt dient, wenn SDS als Quelle für Ihre Zertifikate und Zertifikatsketten dient. Sie können den Pfad zu diesem Endpunkt mithilfe der Umgebungsvariablen konfigurieren. `APPMESH_SDS_SOCKET_PATH` Local Secrets Discovery Service, der Unix Domain Socket verwendet, wird auf der App Mesh Envoy-Proxyversion 1.15.1.0 und höher unterstützt. App Mesh unterstützt das V2-SDS-Protokoll mithilfe von gRPC. **Integration mit der SPIFFE Runtime Environment (SPIRE)** Sie können jede Sidecar-Implementierung der SDS-API verwenden, einschließlich vorhandener Toolchains wie [ SPIFFE Runtime Environment (SPIRE). ](https://github.com/spiffe/spire) SPIRE wurde entwickelt, um die Bereitstellung der gegenseitigen TLS-Authentifizierung zwischen mehreren Workloads in verteilten Systemen zu ermöglichen. Es bestätigt die Identität von Workloads zur Laufzeit. SPIRE liefert außerdem Workload-spezifische, kurzlebige und automatisch rotierende Schlüssel und Zertifikate direkt für Workloads. Sie sollten den SPIRE Agent als SDS-Anbieter für Envoy konfigurieren. Erlauben Sie ihm, Envoy direkt mit dem Schlüsselmaterial zu versorgen, das es für die gegenseitige TLS-Authentifizierung benötigt. Lass SPIRE-Agenten in Beiwagen neben den Envoy-Proxys laufen. Der Agent kümmert sich bei Bedarf darum, die kurzlebigen Schlüssel und Zertifikate neu zu generieren. Der Agent bestätigt Envoy und bestimmt, welche Dienstidentitäten und CA-Zertifikate er Envoy zur Verfügung stellen soll, wenn Envoy eine Verbindung zu dem vom SPIRE Agent bereitgestellten SDS-Server herstellt. Während dieses Vorgangs werden Service-Identitäten und CA-Zertifikate rotiert, und Updates werden zurück an Envoy gestreamt. Envoy wendet sie sofort auf neue Verbindungen an, ohne dass es zu Unterbrechungen oder Ausfallzeiten kommt und ohne dass die privaten Schlüssel jemals das Dateisystem berühren. ## Wie App Mesh Envoys für die Aushandlung von TLS konfiguriert App Mesh verwendet die Mesh-Endpunktkonfiguration sowohl des Clients als auch des Servers, um zu bestimmen, wie die Kommunikation zwischen Envoys in einem Mesh konfiguriert werden soll. **Mit Client-Richtlinien** Wenn eine Client-Richtlinie die Verwendung von TLS erzwingt und einer der Ports in der Client-Richtlinie mit dem Port der Serverrichtlinie übereinstimmt, wird die Client-Richtlinie verwendet, um den TLS-Validierungskontext des Clients zu konfigurieren. Wenn beispielsweise die Client-Richtlinie eines virtuellen Gateways mit der Serverrichtlinie eines virtuellen Knotens übereinstimmt, wird versucht, eine TLS-Aushandlung zwischen den Proxys unter Verwendung der in der Client-Richtlinie des virtuellen Gateways definierten Einstellungen durchzuführen. Wenn die Client-Richtlinie nicht mit dem Port der Serverrichtlinie übereinstimmt, kann je nach den TLS-Einstellungen der Serverrichtlinie TLS zwischen den Proxys ausgehandelt werden oder auch nicht. **Ohne Client-Richtlinien** Wenn der Client keine Client-Richtlinie konfiguriert hat oder die Client-Richtlinie nicht mit dem Port des Servers übereinstimmt, bestimmt App Mesh anhand des Servers, ob und wie TLS vom Client aus ausgehandelt werden soll oder nicht. Wenn beispielsweise ein virtuelles Gateway keine Client-Richtlinie angegeben hat und ein virtueller Knoten die TLS-Terminierung nicht konfiguriert hat, wird TLS nicht zwischen den Proxys ausgehandelt. Wenn ein Client keine entsprechende Client-Richtlinie angegeben hat und ein Server mit TLS-Modi `STRICT` oder konfiguriert wurde, werden die Proxys so konfiguriert`PERMISSIVE`, dass sie TLS aushandeln. Je nachdem, wie die Zertifikate für die TLS-Terminierung bereitgestellt wurden, gilt das folgende zusätzliche Verhalten. + **ACM-managed TLS-Zertifikate ** — Wenn ein Server die TLS-Terminierung mithilfe eines ACM-managed Zertifikats konfiguriert hat, konfiguriert App Mesh die Clients automatisch so, dass sie TLS aushandeln und das Zertifikat anhand der Root-Benutzer-CA validieren, zu der das Zertifikat gehört. + **File-based TLS-Zertifikate ** — Wenn ein Server die TLS-Terminierung mithilfe eines Zertifikats aus dem lokalen Dateisystem des Proxys konfiguriert hat, konfiguriert App Mesh automatisch einen Client für die Aushandlung von TLS, aber das Zertifikat des Servers wird nicht validiert. **Alternative Namen des Betreffs** Sie können optional eine Liste von Subject Alternative Names (SANs) angeben, denen Sie vertrauen sollen. SANs müssen im FQDN- oder URI-Format vorliegen. Wenn SANs bereitgestellt werden, überprüft Envoy, ob der alternative Betreffname des vorgelegten Zertifikats mit einem der Namen in dieser Liste übereinstimmt. Wenn Sie keine SANs auf dem abschließenden Mesh-Endpunkt angeben, verifiziert der Envoy-Proxy für diesen Knoten das SAN auf einem Peer-Client-Zertifikat nicht. Wenn Sie auf dem Ursprungs-Mesh-Endpunkt keine SANs angeben, muss das SAN auf dem vom Zielendpunkt bereitgestellten Zertifikat mit der Konfiguration der Mesh-Endpunkt-Serviceerkennung übereinstimmen. Weitere Informationen finden Sie unter App Mesh [ TLS: Zertifikatsanforderungen. ](https://docs.aws.amazon.com/app-mesh/latest/userguide/tls.html#virtual-node-tls-prerequisites) Sie können Platzhalter-SANs nur verwenden, wenn die Client-Richtlinie für TLS auf `not enforced` festgelegt ist. Wenn die Client-Richtlinie für den virtuellen Knoten oder das virtuelle Gateway so konfiguriert ist, dass TLS erzwungen wird, kann ein Platzhalter-SAN nicht akzeptiert werden. ## Überprüfen Sie die Verschlüsselung Sobald Sie TLS aktiviert haben, können Sie den Envoy-Proxy abfragen, um zu bestätigen, dass die Kommunikation verschlüsselt ist. Der Envoy-Proxy gibt Statistiken zu Ressourcen aus, anhand derer Sie nachvollziehen können, ob Ihre TLS-Kommunikation ordnungsgemäß funktioniert. Beispielsweise zeichnet der Envoy-Proxy Statistiken über die Anzahl erfolgreicher TLS-Handshakes auf, die er für einen bestimmten Mesh-Endpunkt ausgehandelt hat. Ermitteln Sie, wie viele erfolgreiche TLS-Handshakes es für einen Mesh-Endpunkt gab, der mit dem folgenden Befehl benannt wurde`{{my-mesh-endpoint}}`. ``` curl -s 'http://{{my-mesh-endpoint.apps.local}}:9901/stats' | grep ssl.handshake ``` Im folgenden Beispiel wurde eine Ausgabe zurückgegeben, es gab drei Handshakes für den Mesh-Endpunkt, sodass die Kommunikation verschlüsselt ist. ``` listener.0.0.0.0_15000.ssl.handshake: 3 ``` Der Envoy-Proxy gibt auch Statistiken aus, wenn die TLS-Aushandlung fehlschlägt. Stellen Sie fest, ob TLS-Fehler für den Mesh-Endpunkt aufgetreten sind. ``` curl -s 'http://{{my-mesh-endpoint.apps.local}}:9901/stats' | grep -e "ssl.*\(fail\|error\)" ``` In der zurückgegebenen Beispielausgabe gab es für mehrere Statistiken keine Fehler, sodass die TLS-Aushandlung erfolgreich war. ``` 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 ``` Weitere Informationen zu Envoy TLS-Statistiken finden Sie unter [ Envoy Listener Statistics. ](https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/stats) ## Zertifikatserneuerung **AWS Private CA** Wenn Sie ein Zertifikat mit ACM verlängern, wird das erneuerte Zertifikat innerhalb von 35 Minuten nach Abschluss der Verlängerung automatisch an Ihre verbundenen Proxys verteilt. Wir empfehlen, die verwaltete Verlängerung zu verwenden, um Zertifikate, die sich dem Ende ihrer Gültigkeitsdauer nähern, automatisch zu verlängern. Weitere Informationen finden Sie [ im AWS Certificate Manager Benutzerhandbuch unter ](https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html) Verwaltete Verlängerung der Amazon-Issued ACM-Zertifikate. **Ihr eigenes Zertifikat** Wenn Sie ein Zertifikat aus dem lokalen Dateisystem verwenden, lädt Envoy das Zertifikat nicht automatisch neu, wenn es sich ändert. Sie können den Envoy-Prozess entweder neu starten oder erneut bereitstellen, um ein neues Zertifikat zu laden. Sie können auch ein neueres Zertifikat in einem anderen Dateipfad platzieren und die virtuelle Knoten- oder Gateway-Konfiguration mit diesem Dateipfad aktualisieren. ## Konfigurieren Sie Amazon ECS-Workloads für die Verwendung der TLS-Authentifizierung mit AWS App Mesh Sie können Ihr Mesh so konfigurieren, dass es die TLS-Authentifizierung verwendet. Stellen Sie sicher, dass die Zertifikate für Envoy-Proxy-Sidecars verfügbar sind, die Sie zu Ihren Workloads hinzufügen. Sie können ein EBS- oder EFS-Volume an Ihren Envoy-Sidecar anhängen, oder Sie können Zertifikate speichern und von Secrets Manager abrufen. AWS + Wenn Sie die dateibasierte Zertifikatsverteilung verwenden, hängen Sie ein EBS- oder EFS-Volume an Ihren Envoy-Sidecar an. Stellen Sie sicher, dass der Pfad zum Zertifikat und zum privaten Schlüssel mit dem Pfad übereinstimmt, der in konfiguriert ist. AWS App Mesh + Wenn Sie die SDS-based Distribution verwenden, fügen Sie einen Sidecar hinzu, der die SDS-API von Envoy mit Zugriff auf das Zertifikat implementiert. **Anmerkung** SPIRE wird auf Amazon ECS nicht unterstützt. ## Konfigurieren Sie Kubernetes-Workloads für die Verwendung der TLS-Authentifizierung mit AWS App Mesh Sie können den AWS App Mesh Controller für Kubernetes so konfigurieren, dass die TLS-Authentifizierung für Backends und Listener von virtuellen Knoten- und virtuellen Gateway-Services aktiviert wird. Stellen Sie sicher, dass die Zertifikate für die Envoy-Proxy-Sidecars verfügbar sind, die Sie zu Ihren Workloads hinzufügen. Ein Beispiel für jeden Verteilungstyp finden Sie im [ Abschnitt „](https://docs.aws.amazon.com/app-mesh/latest/userguide/mutual-tls.html#mtls-walkthrough)Exemplarische Vorgehensweise“ von Mutual TLS Authentication. + Wenn Sie die dateibasierte Zertifikatsverteilung verwenden, hängen Sie ein EBS- oder EFS-Volume an Ihren Envoy-Sidecar an. Stellen Sie sicher, dass der Pfad zum Zertifikat und zum privaten Schlüssel mit dem im Controller konfigurierten Pfad übereinstimmt. Alternativ können Sie ein Kubernetes-Geheimnis verwenden, das im Dateisystem gemountet ist. + Wenn Sie die SDS-based Distribution verwenden, sollten Sie einen lokalen SDS-Anbieter für Knoten einrichten, der die SDS-API von Envoy implementiert. Envoy wird ihn über UDS erreichen. Um die SDS-basierte mTLS-Unterstützung im AppMesh EKS-Controller zu aktivieren, setzen Sie das `enable-sds` Flag auf `true` und geben Sie über das Flag den UDS-Pfad des lokalen SDS-Anbieters zum Controller an. `sds-uds-path` Wenn Sie Helm verwenden, legen Sie diese als Teil Ihrer Controller-Installation fest: ``` --set sds.enabled=true ``` **Anmerkung** Sie können SPIRE nicht zur Verteilung Ihrer Zertifikate verwenden, wenn Sie Amazon Elastic Kubernetes Service (Amazon EKS) im Fargate-Modus verwenden.