Anthos Service Mesh und Traffic Director heißen jetzt Cloud Service Mesh. Weitere Informationen finden Sie in der Cloud Service Mesh-Übersicht.

Diese Seite wurde von der Cloud Translation API übersetzt.

Anwendungsfälle für die Dienstsicherheit (alt)

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.

Eine Übersicht über die Dienstsicherheit finden Sie unter Sicherheit von Cloud Service Mesh-Diensten.

Dieses Dokument bezieht sich auf Konfigurationen mit den Load Balancing APIs. Dies ist ein älteres Dokument.

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 wird die Beschreibung der globalen Weiterleitungsregel, des Ziel-HTTPS-Proxys und der URL-Zuordnung weggelassen. Diese Compute Engine API-Ressourcen sind zum Erstellen des Mesh-Netzwerks erforderlich. Sie müssen sie jedoch 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 werden die Labels "mesh-service":"true" für die Endpunktrichtlinie und die Cloud Service Mesh-Clients konfiguriert. 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 haben Sie die Möglichkeit, Regeln festzulegen, die bestimmen, 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.
Konfigurieren Sie Cloud Service Mesh so, dass Ihre Cloud Service Mesh-Clients HTTPS beenden und dem Client, in diesem Fall dem Load Balancer, Zertifikate präsentieren.

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 also zwei Gruppen von Compute Engine API-Ressourcen (globale Weiterleitungsregel, Ziel-Proxy, URL-Zuordnung und globale Back-End-Dienste) mit unterschiedlichen Load-Balancing-Schemas:

Eine Gruppe von Ressourcen konfiguriert Ihren Load-Balancer mit dem Load-Balancing-Schema INTERNAL_MANAGED.
Mit den anderen Ressourcen wird Cloud Service Mesh konfiguriert, das das Load-Balancing-Schema INTERNAL_SELF_MANAGED hat.

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:

Erstellen Sie eine Server-TLS-Richtlinie: Konfigurieren Sie terminationTls in transportAuthentication.
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 so konfiguriert ist, dass TLS-Verbindungen zu Diensten in Ihrem Mesh-Netzwerk initiiert werden, muss Cloud Service Mesh Ihre Cloud Service Mesh-Clients nur so konfigurieren, dass sie TLS-Verbindungen beenden.

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 Ihres Mesh-Netzwerks und leitet den Traffic basierend auf der Konfiguration, die er von Cloud Service Mesh empfängt, an Dienste innerhalb des Mesh-Netzwerks weiter. 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.

Im dritten Schritt konfigurieren Sie Cloud Service Mesh so dafür, dass HTTPS beendet wird und Zertifikate angezeigt werden:

Erstellen Sie eine globale Weiterleitungsregel und einen Ziel-HTTPS-Proxy, um den Pfad für eingehenden Traffic in Ihr Mesh-Netzwerk darzustellen.
Hängen Sie die vorhandene URL-Zuordnung für Ihr Mesh-Netzwerk an diesen Ziel-HTTPS-Proxy an. Die URL-Zuordnung enthält bereits Verweise auf die verschiedenen globalen Back-End-Dienste Ihres Mesh-Netzwerks, die auf der Konfiguration basieren, die Sie bei der Konfiguration des Mesh-Netzwerks und von mTLS festgelegt haben.
Erstellen Sie eine Server-TLS-Richtlinie: Konfigurieren Sie serverCertificate.
Hängen Sie die Server-TLS-Richtlinienressource an den Ziel-HTTPS-Proxy 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 eine andere IP-Adresse (in diesem Beispiel 10.0.0.2) an als beim Konfigurieren des Mesh (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 10.0.0.2 (VIP) 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. Sie können die Dienstsicherheit nicht mit der Compute Engine bereitstellen.

Nächste Schritte

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