Anthos Service Mesh und Traffic Director sind jetzt Cloud Service Mesh. Weitere Informationen finden Sie in der Übersicht zum Cloud Service Mesh.

Diese Seite wurde von der Cloud Translation API übersetzt.

Anwendungsfälle für die Dienstsicherheit (Legacy)

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 Dienstsicherheit in Cloud Service Mesh.

Dieses Dokument bezieht sich auf Konfigurationen, die die Load Balancing APIs verwenden. Dies ist ein altes 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 den 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 können Sie Regeln angeben, die bestimmen, ob ein Cloud Service Mesh-Client die Konfiguration empfängt. Diese Regeln basieren auf den xDS-Metadaten, die die Datenebenenentität für die Steuerungsebene bereitstellt – in diesem Fall Cloud Service Mesh.
  
  So können Sie dem Cloud Service Mesh-Client Labels hinzufügen:
  - 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 bei eingehenden Anfragen erzwungen, die einen Port angeben, der sich auch im Feld TRAFFICDIRECTOR_INBOUND_BACKEND_PORTS befindet, das dem Cloud Service Mesh-Client in seinen Bootstrap-Informationen bereitgestellt wird.
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. Damit wird dem Envoy-Proxy oder dem proxylosen Client mitgeteilt, welcher TLS-Modus-, Identitäts- und Peer-Validierungsansatz für die Adressierung des Dienstes verwendet werden soll.
Die TLS-Serverrichtlinie ist an die Endpunktrichtlinie angehängt. Damit wird dem Server mitgeteilt, welcher TLS-Modus, welche Identität und welche Peer-Validierung für eingehende Verbindungen verwendet werden soll.

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 für die Verwendung von TLS-verschlüsselten Kommunikationskanälen erforderlich ist.

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)

Das gleiche Muster gilt, 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:

Sichern 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 Zertifikate für den Client anzeigen, der in diesem Fall der Load-Balancer ist.

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.
Der andere Satz von Ressourcen konfiguriert das Cloud Service Mesh, 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 den Clients Zertifikate präsentieren.

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 einen TrafficPortSelector, der die Richtlinien nur anwendet, wenn eingehende Anfragen an den angegebenen Port auf dem Cloud Service Mesh-Client gesendet werden.

Da der externe Application Load Balancer bereits zum Initiieren von TLS-Verbindungen zu Diensten in Ihrem Mesh konfiguriert ist, muss Cloud Service Mesh Ihre Cloud Service Mesh-Clients nur so konfigurieren, 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-Netzwerks und leitet den Traffic anhand 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 im dritten Schritt Cloud Service Mesh so, dass HTTPS beendet 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 an (in diesem Beispiel 10.0.0.2) als die, die Sie beim Konfigurieren des Mesh-Netzwerks angegeben haben (in diesem Beispiel lautet die Mesh-Adresse 10.0.0.1). Clients, die über eine von Cloud Service Mesh konfigurierte xDS-Datenebene 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 von Cloud Service Mesh konfiguriertes Service Mesh.

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 von Cloud Service Mesh-Diensten wird nur von GKE unterstützt. Mit Compute Engine können Sie keine Dienstsicherheit bereitstellen.

Nächste Schritte

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