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

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 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, wird der Steuerungsebene bereitgestellt. 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 Das Feld TRAFFICDIRECTOR_INBOUND_BACKEND_PORTS wird bereitgestellt. in den Bootstrap-Informationen an den Cloud Service Mesh-Client.
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 Kunden außerhalb von Google Cloud können Sie externen Application Load Balancer. 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, wenn Sie ein internen Application Load Balancer 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.

Beim Einrichten der Cloud Service Mesh-Sicherheit 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.
In der anderen Gruppe von Ressourcen wird das Cloud Service Mesh konfiguriert, das die 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:

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. Definieren Sie optional eine TrafficPortSelector, die die nur wenn eingehende Anfragen an den angegebenen Port am dem Cloud Service Mesh-Client.

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

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

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 Abschnitt Diagramm: Sie geben bei der Konfiguration der globalen Weiterleitungsregel ein eine andere IP-Adresse hat (in diesem Beispiel 10.0.0.2) als die, die angegeben wird, wenn konfigurieren Sie das Mesh-Netzwerk (in diesem Beispiel ist die Mesh-Adresse 10.0.0.1). Clients, die über eine von Cloud Service Mesh konfigurierte xDS-Datenebene kommunizieren Entität kann diese Adresse für den Zugriff auf das Ingress-Gateway verwenden.

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 Sicherheit des Cloud Service Mesh-Dienstes wird nur unterstützt mit GKE 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 (alt) einrichten.
So konfigurieren Sie die Cloud Service Mesh-Dienstsicherheit mit proxylosen gRPC-Anwendungen: Siehe Cloud Service Mesh-Dienstsicherheit mit proxylosem gRPC (Legacy) einrichten.