Transport Layer Security (TLS)

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 Virtuelle Gateways Der Proxy handelt TLS aus und beendet es. Wenn der Proxy 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.

App Mesh ermöglicht es Ihnen, das TLS-Zertifikat auf folgende Weise für den Proxy bereitzustellen:

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

En) Proxy-Autorisierungmuss für den bereitgestellten Envoy-Proxy aktiviert sein, der durch einen Mesh-Endpunkt repräsentiert 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 tatsächliche Service, der durch einen Mesh-Endpunkt repräsentiert wird, erkannt wird.

• DNS — Eines der Zertifikats-SANs muss dem in den Einstellungen für die DNS-Diensterkennung angegebenen Wert entsprechen. Für eine Anwendung mit dem Namen der Diensterkennung können Sie ein Zertifikat erstellenmesh-endpoint.apps.local, das diesem Namen entspricht, oder ein Zertifikat mit dem Platzhalter*.apps.local.

• AWS Cloud Map— Eines der Zertifikats-SANs muss mit dem Wert übereinstimmen, der in den AWS Cloud Map Service Discovery-Einstellungen unter Verwendung des Formats angegeben wurdeservice-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 erstellenapps.local, das dem Namen entsprichtmesh-endpoint.apps.local, oder ein Zertifikat mit dem Platzhalter *.apps.local.

Für beide Erkennungsmechanismen gilt: Wenn keines der Zertifikats-SANs den Einstellungen für die DNS-Diensterkennung entspricht, schlägt die Verbindung zwischen Envoys fehl und es wird die folgende Fehlermeldung angezeigt, die vom Client Envoy 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 Zertifizierungsstelle muss sich nicht im selben AWS Konto befinden, aber es muss sich dennoch in derselben Region wie der Mesh-Endpunkt befinden. Wenn Sie noch kein Zertifikat haben AWS Private CA, müssen Sie eines erstellen, bevor Sie ein Zertifikat von diesem anfordern können. Weitere Informationen zum Anfordern eines Zertifikats von einem vorhandenen AWS Private CA mithilfe von ACM finden Sie unter Anfordern eines privaten Zertifikats. Das Zertifikat kann kein öffentliches Zertifikat sein.

Bei den privaten Zertifizierungsstellen, die Sie für TLS-Client-Richtlinien verwenden, muss es sich um Root-Benutzer-CAs handeln.

Um einen virtuellen Knoten mit Zertifikaten und Zertifizierungsstellen von zu konfigurieren AWS Private CA, muss der Prinzipal (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 Principal über die entsprechende Berechtigung verfügen. acm:DescribeCertificate

• Für alle Zertifizierungsstellen, die mit einer TLS-Client-Richtlinie konfiguriert sind, muss der Principal über die acm-pca:DescribeCertificateAuthority entsprechende Berechtigung verfügen.

Wichtig

Die gemeinsame Nutzung von Zertifizierungsstellen mit anderen Konten kann dazu führen, dass diese Konten unbeabsichtigte Rechte für die Zertifizierungsstelle erhalten. Wir empfehlen, ressourcenbasierte Richtlinien zu verwenden, um den Zugriff nur acm-pca:DescribeCertificateAuthority auf Konten zu beschränken, acm-pca:GetCertificateAuthorityCertificate für die keine Zertifikate von der Zertifizierungsstelle ausgestellt werden müssen.

Sie können diese Berechtigungen zu einer vorhandenen IAM-Richtlinie hinzufügen, die einem Prinzipal zugeordnet ist, oder einen neuen Prinzipal und eine neue Richtlinie erstellen und die Richtlinie dem Prinzipal zuordnen. Weitere Informationen finden Sie unter Bearbeiten von IAM-Richtlinien, Erstellen von IAM-Richtlinien und Hinzufügen von IAM-Identitätsberechtigungen.

Anmerkung

Sie zahlen eine monatliche Gebühr für den Betrieb der einzelnen Geräte, 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 -Preisgestaltung.

Wenn Sie die Proxyautorisierung 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 über das Secrets Discovery-Protokoll Geheimnisse wie TLS-Zertifikate von einem bestimmten Endpunkt ab. Weitere Informationen zu diesem Protokoll finden Sie in der SDS-Dokumentation von Envoy.

App Mesh konfiguriert den Envoy-Proxy so, dass er einen lokalen Unix-Domain-Socket verwendet, der 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

Wichtig

Local Secrets Discovery Service, der Unix Domain Socket verwendet, wird auf App Mesh Envoy Proxy Version 1.15.1.0 und höher unterstützt.

App Mesh unterstützt das V2 SDS-Protokoll mit gRPC.

Integration mit SPIFFE Runtime Environment (SPIRE)

Sie können jede beliebige Sidecar-Implementierung der SDS-API verwenden, einschließlich vorhandener Toolchains wie SPIFFE Runtime Environment (SPIRE). SPIRE wurde entwickelt, um die Implementierung der gegenseitigen TLS-Authentifizierung zwischen mehreren Workloads in verteilten Systemen zu ermöglichen. Es bestätigt die Identität von Workloads zur Laufzeit. SPIRE stellt außerdem für Workloads spezifische, kurzlebige und automatisch rotierende Schlüssel und Zertifikate direkt für Workloads bereit.

Sie sollten den SPIRE-Agenten 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. Führen Sie SPIRE-Agenten in Sidecars neben Envoy-Proxys aus. Der Agent kümmert sich bei Bedarf um die Neugenerierung der kurzlebigen Schlüssel und Zertifikate. 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 offengelegten SDS-Server herstellt.

Während dieses Vorgangs werden Dienstidentitä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.

So konfiguriert App Mesh Envoys für die Aushandlung von TLS

App Mesh verwendet die Mesh-Endpunktkonfiguration des Clients und 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 dem Port der Serverrichtlinie entspricht, 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, mithilfe der in der Client-Richtlinie des virtuellen Gateways definierten Einstellungen eine TLS-Verhandlung zwischen den Proxys 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, verwendet App Mesh den Server, um zu bestimmen, ob und wie TLS vom Client ausgehandelt werden soll oder nicht. Wenn beispielsweise ein virtuelles Gateway keine Client-Richtlinie angegeben hat und ein virtueller Knoten keine TLS-Terminierung konfiguriert hat, wird TLS nicht zwischen den Proxys ausgehandelt. Wenn ein Client keine passende Client-Richtlinie angegeben hat und ein Server mit TLS-Modi STRICT oder konfiguriert wurde, werden die Proxys so konfiguriertPERMISSIVE, dass sie TLS aushandeln. Je nachdem, wie die Zertifikate für die TLS-Terminierung bereitgestellt wurden, gilt das folgende zusätzliche Verhalten.

• Von ACM verwaltete TLS-Zertifikate — Wenn ein Server die TLS-Terminierung mithilfe eines von ACM verwalteten Zertifikats konfiguriert hat, konfiguriert App Mesh die Clients automatisch so, dass sie TLS aushandeln und das Zertifikat anhand der Root-Benutzer-CA validieren, mit der das Zertifikat verknüpft ist.

• Dateibasierte 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 für den Betreff

Sie können optional eine Liste mit alternativen Namen (Subject Alternative Names, SANs) angeben, denen Sie vertrauen möchten. SANs müssen im FQDN- oder URI-Format vorliegen. Wenn SANs bereitgestellt werden, überprüft Envoy, ob der alternative Subject Name des vorgelegten Zertifikats mit einem der Namen auf 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.

Wichtig

Sie können Wildcard-SANs nur verwenden, wenn die Client-Richtlinie für TLS auf not enforced eingestellt ist. Wenn die Client-Richtlinie für den virtuellen Clientknoten oder das virtuelle Gateway so konfiguriert ist, dass TLS erzwungen wird, kann sie kein Platzhalter-SAN akzeptieren.

Ü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 über Ressourcen aus, anhand derer Sie nachvollziehen können, ob Ihre TLS-Kommunikation ordnungsgemäß funktioniert. Beispielsweise zeichnet der Envoy-Proxy Statistiken über die Anzahl der erfolgreichen 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 wurdemy-mesh-endpoint.

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

In der folgenden Beispielausgabe wurden drei Handshakes für den Mesh-Endpunkt zurückgegeben, 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-Verhandlung 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.

Zertifikatserneuerung

AWS Private CA

Wenn Sie ein Zertifikat mit ACM erneuern, 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 Benutzerhandbuch unter Managed Renewal für die von Amazon ausgestellten Zertifikate von ACM. AWS Certificate Manager

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 ein neueres Zertifikat auch in einem anderen Dateipfad platzieren und die Konfiguration des virtuellen Knotens oder des Gateways 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 für die Verwendung der TLS-Authentifizierung konfigurieren. 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 Ihre Envoy-Sidecar anhängen oder Zertifikate von Secrets Manager speichern und abrufen. AWS

• Wenn Sie die dateibasierte Zertifikatsverteilung verwenden, fügen Sie Ihrem Envoy-Sidecar ein EBS- oder EFS-Volume hinzu. 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 eine SDS-basierte 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 er die TLS-Authentifizierung für Backends und Listener von virtuellen Knoten- und virtuellen Gateway-Services aktiviert. 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 in der exemplarischen Vorgehensweise von Mutual TLS Authentication.

• Wenn Sie die dateibasierte Zertifikatsverteilung verwenden, fügen Sie Ihrem Envoy-Sidecar ein EBS- oder EFS-Volume hinzu. 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-Secret verwenden, das im Dateisystem bereitgestellt wird.

• Wenn Sie eine SDS-basierte Distribution verwenden, sollten Sie einen lokalen SDS-Anbieter für Knoten einrichten, der die SDS-API von Envoy implementiert. Envoy wird es ü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 den UDS-Pfad des lokalen SDS-Anbieters zum Controller über das Flag an. sds-uds-path Wenn Sie Helm verwenden, legen Sie Folgendes als Teil Ihrer Controller-Installation fest:

  --set sds.enabled=true

Anmerkung

Sie können SPIRE nicht für die Verteilung Ihrer Zertifikate verwenden, wenn Sie Amazon Elastic Kubernetes Service (Amazon EKS) im Fargate-Modus verwenden.