Sie sehen die Dokumentation zum Service Mesh für Version 1.22.

Verfügbare Versionen

Cloud Service Mesh
1.22-Archiv
1.21-Archiv
1.20-Archiv
1.19-Archiv
1.18-Archiv

Diese Seite wurde von der Cloud Translation API übersetzt.

Anwendungsfälle für die Dienstsicherheit

In diesem Dokument werden gängige Anwendungsfälle für die Sicherheit von Cloud Service Mesh beschrieben. Anhand dieser Informationen können Sie ermitteln, welches Sicherheitsmodell am besten für Sie geeignet ist. Dieses Dokument bietet auch eine allgemeine Übersicht über die Konfiguration für die einzelnen Anwendungsfälle.

Einen Überblick über die Dienstsicherheit finden Sie unter Sicherheit von Cloud Service Mesh-Diensten

mTLS für Dienste im Mesh-Netzwerk aktivieren

In einem Service Mesh können Sie gegenseitiges TLS (mutual TLS, mTLS) aktivieren, damit sowohl der Client als auch der Server in einer Kommunikation ihre Identität nachweisen und die Kommunikation verschlüsseln müssen.

mTLS-Authentifizierung in einem Service Mesh — Gegenseitige TLS-Authentifizierung (mTLS) in einem Service Mesh (zum Vergrößern klicken)

Im folgenden Abschnitt werden die Ressourcen Mesh, Gateway und Route nicht behandelt. Diese API-Ressourcen sind erforderlich, um Ihr Mesh-Netzwerk und Ihre Route zu erstellen Sie müssen sie aber nicht aktualisieren, um mTLS zu aktivieren.

Das vorhergehende Muster kann durch Konfigurieren der folgenden Compute Engine API-Ressourcen erreicht werden. Dieses Diagramm verwendet Sidecar-Proxys, aber die Konfiguration einer proxylosen gRPC-Anwendung mit mTLS verwendet dieselben Ressourcen.

Compute Engine API-Ressourcen für mTLS innerhalb eines Mesh-Netzwerks — Compute Engine API-Ressourcen für mTLS in einem Mesh-Netzwerk (zum Vergrößern klicken)

Um dieses Modell zu erstellen, gehen Sie folgendermaßen vor:

Erstellen Sie eine Client-TLS-Richtlinie (Transport Layer Security).
Erstellen Sie eine Server-TLS-Richtlinie.
Aktualisieren Sie das Feld securitySettings in Ihren vorhandenen globalen Back-End-Diensten, um auf die neue Client-TLS-Richtlinie zu verweisen.
Erstellen Sie eine Endpunktrichtlinie:
1. Verweisen Sie im Feld server_tls_policy auf die Server-TLS-Richtlinie.
2. Definieren Sie einen EndpointMatcher, um die Cloud Service Mesh-Clients auszuwählen, die die Authentifizierung für eingehenden Traffic erzwingen sollen.
  
  Die Auswahl von Cloud Service Mesh-Clients basiert auf Labels, die in der Bootstrap-Konfiguration des Cloud Service Mesh-Clients angegeben sind. Diese Labels können manuell oder basierend auf den Labels bereitgestellt werden, die an Ihre GKE-Bereitstellungen (Google Kubernetes Engine) übergeben werden.
  
  Im vorherigen Diagramm sind die Labels "mesh-service":"true" die in der Endpunktrichtlinie und den Cloud Service Mesh-Clients konfiguriert wurden. Sie können die Labels entsprechend Ihrer Bereitstellung auswählen.
3. Optional können Sie einen TrafficPortSelector definieren, der die Richtlinien nur anwendet, wenn eingehende Anfragen an den angegebenen Port der Datenebenen-Entität gesendet werden.

Das folgende Diagramm zeigt die Compute Engine-Ressourcen, die Sie für mTLS konfigurieren, unabhängig davon, ob Sie Envoy oder eine proxylose gRPC-Anwendung verwenden.

Das folgende Diagramm zeigt den Trafficfluss und die Compute Engine API-Ressourcen, die Sie für die Aktivierung von mTLS konfigurieren. Der lokale Sidecar-Proxy, der sich neben dem GKE-Pod von Dienst B befindet, ist der Endpunkt in der Kommunikation.

Compute Engine API-Ressourcen und Trafficfluss für mTLS innerhalb eines Mesh-Netzwerks — Compute Engine API-Ressourcen und Trafficfluss für mTLS in einem Mesh-Netzwerk (zum Vergrößern klicken)

Die Endpunktrichtlinie tut Folgendes:

Wählt einen Satz von Endpunkten mit einem Endpunkt-Matcher und optional Ports für diese Endpunkte aus.
1. Mit dem Endpunkt-Matcher können Sie Regeln angeben, Ob ein Cloud Service Mesh-Client die Konfiguration empfängt. Diese Regeln basieren auf den xDS-Metadaten, die die Entität der Datenebene für die Steuerungsebene bereitstellt, in diesem Fall Cloud Service Mesh.
  
  So fügen Sie dem Cloud Service Mesh-Client Labels hinzu:
  - Sie können diese Metadaten manuell in der Bootstrap-Datei Ihres Cloud Service Mesh-Clients angeben.
  - Alternativ können die Metadaten automatisch ausgefüllt werden, wenn Sie GKE verwenden. Fügen Sie dazu die Schlüssel/Wert-Paare in den Dateien demo_server.yaml oder demo_client.yaml dem Abschnitt env hinzu. Diese Werte finden Sie im Envoy-Einrichtungsleitfaden und im Leitfaden für proxyloses gRPC.
    
    Beispiel: Nur in Envoy können Sie dem Schlüssel das Präfix ISTIO_META_ voranstellen. Die Namen von Proxy-Umgebungsvariablen, die mit ISTIO_META_ beginnen, sind im generierten Bootstrap enthalten und werden an den xDS-Server gesendet.
```
- name: ISTIO_META_app
  value: 'review'
- name: ISTIO_META_version
  value: 'canary'
```
2. Wenn Sie einen Port angeben, werden die in der Endpunktrichtlinie referenzierten Richtlinien nur für eingehende Anfragen erzwungen, die denselben Port angeben. Wenn Sie keinen Port angeben, werden die Richtlinien für eingehende Anfragen erzwungen, die einen Port angeben, der auch im Feld TRAFFICDIRECTOR_INBOUND_BACKEND_PORTS enthalten ist. Dieses Feld wird auch für den Cloud Service Mesh-Client in den Bootstrap-Informationen bereitgestellt.
Referenziert Client-TLS-, Server-TLS- und Autorisierungsrichtlinien, die die Endpunkte konfigurieren, zu denen Anfragen aufgelöst werden.

Das Konfigurieren von inkompatiblen TLS-Modi kann zu einer Unterbrechung der Kommunikation führen. Wenn Sie beispielsweise OPEN für den globalen Back-End-Dienst festlegen oder das Feld für die Client-TLS-Richtlinie leer lassen und MTLS als Wert der Server-TLS-Richtlinie für die Endpunktrichtlinie festlegen, treten Fehler bei Kommunikationsversuchen auf. Dies liegt daran, dass Endpunkte, die so konfiguriert sind, dass sie nur mTLS-Ablehnungsversuche akzeptieren, um nicht authentifizierte Kommunikationskanäle einzurichten.

Beachten Sie die Unterscheidung zwischen einer Client-TLS-Richtlinie und einer Server-TLS-Richtlinie, die an einen globalen Back-End-Dienst bzw. eine globale Endpunktrichtlinie angehängt ist:

Die Client-TLS-Richtlinie wird auf den globalen Back-End-Dienst angewendet und teilt dem Envoy-Proxy oder proxylosen Client den TLS-Modus, die Identität und den Peer-Validierungsansatz mit, die beim Adressieren dieses Dienstes verwendet werden sollen.
Die Server-TLS-Richtlinie ist mit der Endpunktrichtlinie verknüpft und teilt dem Server mit, welcher TLS-Modus, welche Identität und welcher Peer-Validierungsansatz für eingehende Verbindungen verwendet werden sollen.

TLS für ein Ingress-Gateway aktivieren

Nachdem Sie gegenseitiges TLS für die interne Kommunikation des Mesh-Netzwerks eingerichtet haben, möchten Sie möglicherweise Traffic sichern, der in Ihr Mesh-Netzwerk gelangt (eingehender Traffic). Cloud Service Mesh kann Ihre Datenebene so konfigurieren, dass eingehender Traffic TLS-verschlüsselte Kommunikationskanäle verwenden muss.

Wählen Sie zum Erreichen dieses Ziels eine der folgenden Architekturoptionen aus:

Dienste im Mesh-Netzwerk beenden TLS für Traffic von einem Load-Balancer. In diesem Modell wird jeder Dienst im Mesh-Netzwerk als Back-End in der Konfiguration des Load-Balancers konfiguriert, genauer gesagt, in der URL-Zuordnung des Load-Balancers.
Ein Ingress-Gateway beendet TLS für Traffic von einem Load-Balancer, bevor es Traffic an Dienste im Mesh-Netzwerk weiterleitet. In diesem Modell wird ein dedizierter Dienst im Mesh-Netzwerk, das Ingress-Gateway, als Back-End in der Konfiguration des Load-Balancers konfiguriert, genauer gesagt, in der URL-Zuordnung des Load-Balancers.

Beide Optionen werden in diesem Abschnitt erläutert.

Dienste im Mesh-Netzwerk beenden TLS für Traffic von einem Load-Balancer

Wenn Sie Ihre Dienste für Clients außerhalb von Google Cloud verfügbar machen möchten, können Sie einen externen Application Load Balancer verwenden. Clients senden Traffic an die globale virtuelle Anycast-IP-Adresse (VIP) des Load-Balancers, die diesen Traffic dann an Dienste in Ihrem Mesh-Netzwerk weiterleitet. Dies bedeutet, dass zwei Verbindungen vorhanden sind, wenn ein externer Client einen Dienst im Mesh-Netzwerk erreichen muss.

TLS zu einem Dienst im Mesh-Netzwerk. — TLS zu einem Dienst im Mesh-Netzwerk (zum Vergrößern klicken)

Dasselbe Muster gilt auch, wenn Sie einen internen Application Load Balancer verwenden. Der Traffic von internen Clients erreicht zuerst den Load-Balancer und stellt dann eine Verbindung zum Back-End her.

So sichern Sie beide Verbindungen:

Schützen Sie die Verbindung zwischen dem Client und dem Load Balancer mithilfe eines externen Application Load Balancers.
Konfigurieren Sie den Load-Balancer so, dass er die HTTPS- oder HTTP/2-Protokolle verwendet, wenn er versucht, eine Verbindung mit Diensten im Mesh-Netzwerk aufzubauen.
Cloud Service Mesh so konfigurieren, dass Ihre Cloud Service Mesh-Clients beendet werden HTTPS und stellt dem Client Zertifikate vor. In diesem Fall ist dies die Load Balancer.

Weitere Informationen zu den Schritten 1 und 2 finden Sie unter Multiregionalen, inhaltsbasierten externen HTTPS-Load-Balancer einrichten.

Wenn Sie die Cloud Service Mesh-Sicherheit einrichten, konfigurieren Sie verschiedene Compute Engine API-Ressourcen. Diese Ressourcen sind von den Ressourcen getrennt, die Sie für den Load-Balancer konfigurieren. Sie erstellen eine Reihe von Compute Engine API-Ressourcen (globale Weiterleitungsregel, Zielproxy, URL-Zuordnung, und globale Back-End-Dienste) für den Load-Balancer Cloud Service Mesh mit den Dienstrouting-APIs Außerdem muss im Back-End Dienstressource, hat der Load-Balancer das Load-Balancing-Schema INTERNAL_MANAGED und Cloud Service Mesh hat das Load-Balancing-Schema INTERNAL_SELF_MANAGED.

In Schritt 3 konfigurieren Sie Cloud Service Mesh so, dass Ihre Cloud Service Mesh-Clients HTTPS beenden und Zertifikate an Clients übergeben.

Compute Engine API-Ressourcen für TLS zum Dienst im Mesh-Netzwerk (zum Vergrößern klicken)

In diesem Modell tun Sie Folgendes:

serverTlsPolicy erstellen: serverCertificate konfigurieren Die Ressource serverTlsPolicy.
Erstellen Sie eine Endpunktrichtlinie:
1. Verweisen Sie im Feld authentication auf die Server-TLS-Richtlinie.
2. Definieren Sie einen EndpointMatcher, um die Entitäten der xDS-Datenebene auszuwählen, die die Authentifizierung für eingehenden Traffic erzwingen sollen.
3. Optional können Sie einen TrafficPortSelector definieren, der die Richtlinien nur anwendet, wenn eingehende Anfragen an den angegebenen Port des Cloud Service Mesh-Clients gesendet werden.

Da der externe Application Load Balancer bereits zum Initiieren TLS-Verbindungen zu Diensten in Ihrem Mesh, muss Cloud Service Mesh Konfigurieren Sie Ihre Cloud Service Mesh-Clients so, dass TLS-Verbindungen beendet werden.

Ingress-Gateway beendet TLS für Traffic von einem Load-Balancer, bevor Traffic an Dienste im Mesh-Netzwerk weitergeleitet wird

Wenn Sie dem Load-Balancer nur ein Ingress-Gateway zur Verfügung stellen möchten, können Sie das Ingress-Gateway-Bereitstellungsmuster verwenden. In diesem Muster spricht der Load-Balancer die Dienste in Ihrem Mesh-Netzwerk nicht direkt an. Stattdessen befindet sich ein mittlerer Proxy, am Rand des Mesh und leitet den Traffic an Dienste innerhalb des Mesh weiter, für die Konfiguration, die es vom Cloud Service Mesh empfängt. Der mittlere Proxy kann ein Envoy-Proxy sein, den Sie auf VM-Instanzen in einer von Compute Engine verwalteten Instanzgruppe bereitgestellt haben.

TLS zu einem Ingress-Gateway mit mTLS innerhalb eines Mesh-Netzwerks (zum Vergrößern klicken)

Aus der Sicherheitsperspektive konfigurieren Sie das Ingress-Gateway so, dass TLS beendet wird, und konfigurieren optional Verbindungen innerhalb Ihres Mesh-Netzwerks, die durch mTLS geschützt werden sollen. Dazu gehören Verbindungen zwischen dem Ingress-Gateway und Ihren Diensten im Mesh-Netzwerk sowie Verbindungen zwischen den Diensten im Mesh-Netzwerk.

In Bezug auf die Konfiguration tun Sie Folgendes:

Konfigurieren Sie Ihr Service Mesh und aktivieren Sie mTLS für die Kommunikation innerhalb des Mesh-Netzwerks (wie zuvor erläutert).
Konfigurieren Sie Ihren Load-Balancer so, dass Traffic an das Ingress-Gateway weitergeleitet und Verbindungen mithilfe des HTTPS-Protokolls initiiert werden (wie zuvor erläutert).
Erstellen Sie eine Reihe von Compute Engine API-Ressourcen, die das Ingress-Gateway und seine Server-TLS-Richtlinie darstellen.

Konfigurieren Sie für den dritten Schritt das Cloud Service Mesh so, dass HTTPS und präsentieren Zertifikate so:

Erstellen Sie eine Mesh-Ressource, die das Mesh-Netzwerk darstellt.
Erstellen Sie eine Route-Ressource, die auf die richtigen globalen Back-End-Dienste verweist, und hängen Sie die Route-Ressource an die Mesh-Ressource an.
Erstellen Sie eine Server-TLS-Richtlinie: Konfigurieren Sie serverCertificate.
Erstellen Sie eine Gateway-Ressource, die das vom Cloud Service Mesh verwaltete Ingress-Gateway darstellt.
Hängen Sie die TLS-Richtlinienressource des Servers an die Ressource Gateway an.

Das Ingress-Gateway-Muster ist besonders in großen Organisationen nützlich, die eine freigegebene VPC verwenden. In einer solchen Situation erlaubt ein Team eventuell nur den Zugriff auf seine Dienste über ein Ingress-Gateway. Im vorherigen Diagramm geben Sie beim Konfigurieren der globalen Weiterleitungsregel für den Load Balancer eine andere IP-Adresse (in diesem Beispiel 10.0.0.2) an als bei der Konfiguration des Mesh-Netzwerks (in diesem Beispiel ist die Mesh-Adresse 10.0.0.1). Clients, die über eine von Cloud Service Mesh konfigurierte xDS-Datenebenen-Entität kommunizieren, können diese Adresse verwenden, um auf das Ingress-Gateway zuzugreifen.

Beispiel:

Zwei Dienstprojekte (1 und 2) sind an dasselbe freigegebene VPC-Netzwerk angeschlossen.
Dienstprojekt 1 enthält ein Service Mesh, das von Cloud Service Mesh konfiguriert ist.

Dienstprojekt 1 hat ein Mesh-Netzwerk und ein Ingress-Gateway konfiguriert. Dieses Ingress-Gateway ist über die Adresse/VIP 10.0.0.2 erreichbar.
Dienstprojekt 2 enthält ein von Cloud Service Mesh konfiguriertes Service Mesh.

Dienstprojekt 2 kann ein eigenes Ingress-Gateway haben, muss aber nicht.
Cloud Service Mesh konfiguriert die Cloud Service Mesh-Clients in jedem Dienstprojekt. Für die Clients erfolgt ein Bootstrapping, sodass sie dasselbe Netzwerk verwenden.

Bei dieser Konfiguration können Clients im Mesh-Netzwerk von Dienstprojekt 2 über die VIP 10.0.0.2 mit dem Ingress-Gateway in Dienstprojekt 1 kommunizieren. Auf diese Weise können die Inhaber von Dienstprojekt 1 Routing-, Sicherheits- und andere Richtlinien konfigurieren, die für den in das Mesh-Netzwerk eingehenden Traffic spezifisch sind. Die Inhaber des Dienstprojekts 1 können somit anderen sagen, dass Clients in deren Mesh-Netzwerk ihre Dienste unter 10.0.0.2 erreichen können.

Beschränkungen

Die Cloud Service Mesh-Dienstsicherheit wird nur mit GKE unterstützt. Mit Compute Engine können Sie Dienstsicherheit nicht bereitstellen.

Nächste Schritte

Informationen zum Konfigurieren der Cloud Service Mesh-Dienstsicherheit mit Envoy-Proxys finden Sie unter Cloud Service Mesh-Dienstsicherheit mit Envoy einrichten.
Informationen zum Konfigurieren der Cloud Service Mesh-Dienstsicherheit mit proxylosen gRPC-Anwendungen finden Sie unter Cloud Service Mesh-Dienstsicherheit mit proxylosem gRPC einrichten.