Sicherheit auf Transportschicht (TLS)

Das Zertifikat muss 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 bestehenden AWS Private CA Benutzer ACM finden Sie unter Privates Zertifikat anfordern. Das Zertifikat kann kein öffentliches Zertifikat sein.

Das private ObjektCAs, das Sie für TLS Client-Richtlinien verwenden, muss ein Root-Benutzer seinCAs.

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:

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 IAMRichtlinien bearbeiten, IAMRichtlinien erstellen und IAMIdentitätsberechtigungen hinzufügen.

Wenn Sie die Proxyautorisierung für den Envoy-Proxy aktivieren, den ein Mesh-Endpunkt darstellt, müssen der IAM Rolle, die Sie verwenden, die folgenden IAM Berechtigungen zugewiesen werden:

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.

Envoy ruft Geheimnisse wie TLS Zertifikate von einem bestimmten Endpunkt über das Secrets Discovery-Protokoll ab. Weitere Informationen zu diesem Protokoll finden Sie in der Dokumentation von Envoy. SDS

App Mesh konfiguriert den Envoy-Proxy so, dass er einen lokalen Unix-Domain-Socket verwendet, der als Secret Discovery Service (SDS) -Endpunkt SDS dient, wenn er als Quelle für Ihre Zertifikate und Zertifikatsketten dient. Sie können den Pfad zu diesem Endpunkt mithilfe der APPMESH_SDS_SOCKET_PATH Umgebungsvariablen konfigurieren.

Sie können jede beliebige Sidecar-Implementierung von verwenden SDSAPI, einschließlich vorhandener Toolchains wie SPIFFERuntime Environment (). SPIRE SPIREwurde 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. SPIREstellt 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 Anbieter für Envoy konfigurieren. SDS Erlauben Sie ihm, Envoy direkt mit dem Schlüsselmaterial zu versorgen, das er für die gegenseitige TLS Authentifizierung benötigt. Führen Sie SPIRE Agenten in Beiwagen 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 Agenten offengelegten Server herstellt. SDS SPIRE

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.

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, 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 Einstellungen der Serverrichtlinie TLS zwischen den Proxys ausgehandelt werden oder auch nicht. TLS

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 vom Client TLS aus verhandelt werden soll oder nicht. Wenn beispielsweise ein virtuelles Gateway keine Client-Richtlinie angegeben hat und ein virtueller Knoten keine TLS Terminierung konfiguriert hat, TLS wird zwischen den Proxys nicht 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 aushandeln. TLS Je nachdem, wie die Zertifikate für die TLS Kündigung bereitgestellt wurden, gilt das folgende zusätzliche Verhalten.

Sie können optional eine Liste mit alternativen Betreffnamen (SANs) angeben, denen Sie vertrauen möchten. SANsmuss im URI Format FQDN oder sein. Falls SANs angegeben, überprüft Envoy, ob der alternative Betreffname des vorgelegten Zertifikats mit einem der Namen auf dieser Liste übereinstimmt.

Wenn Sie SANs auf dem abschließenden Mesh-Endpunkt nichts angeben, überprüft der Envoy-Proxy für diesen Knoten das Zertifikat SAN auf einem Peer-Client nicht. Wenn Sie auf dem ursprünglichen Mesh-Endpunkt nichts angeben, muss das SANs SAN auf dem Zertifikat, das vom terminierenden Endpunkt bereitgestellt wird, mit der Mesh-Endpunkt-Serviceerkennungskonfiguration übereinstimmen.

Weitere Informationen finden Sie unter App Mesh TLS: Zertifikatsanforderungen.