Anthos Service Mesh am Beispiel: mTLS

---

In Anthos Service Mesh 1.5 und höher ist die automatische gegenseitige TLS-Authentifizierung (automatisches mTLS) standardmäßig aktiviert. Bei automatischem mTLS erkennt ein Client-Sidecar-Proxy automatisch, ob der Server einen Sidecar hat. Der Client-Sidecar-Proxy sendet an Arbeitslasten mit Sidecars mTLS und an Arbeitslasten ohne Sidecars Klartext-Traffic. Dienste akzeptieren dagegen sowohl Klartext- als auch mTLS-Traffic. Wenn Sie Sidecar-Proxys in Ihre Pods einfügen, empfehlen wir Ihnen, Ihre Dienste auch so zu konfigurieren, dass nur mTLS-Traffic akzeptiert wird.

Mit Anthos Service Mesh können Sie mTLS außerhalb Ihres Anwendungscodes durch Anwenden einer einzelnen YAML-Datei erzwingen. Anthos Service Mesh bietet Ihnen die Flexibilität, eine Authentifizierungsrichtlinie auf das gesamte Service Mesh, auf einen Namespace oder auf eine einzelne Arbeitslast anzuwenden.

Kosten

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

• GKE
• Anthos Service Mesh

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Nach Abschluss dieser Anleitung können Sie weitere Kosten durch Löschen von erstellten Ressourcen vermeiden. Weitere Informationen finden Sie unter Bereinigen.

Hinweise

In dieser Anleitung wird die Beispielanwendung Online Boutique verwendet, um das Konfigurieren von mTLS auf einem GKE-Cluster zu demonstrieren, auf dem Anthos Service Mesh installiert ist.

• Wenn Sie für diese Anleitung einen GKE-Cluster einrichten müssen, lesen Sie die Kurzanleitung für Anthos Service Mesh. Darin werden Ihnen die Einrichtung eines Clusters, die Installation von Anthos Service Mesh und die Bereitstellung des Online-Boutique-Beispiels im Namespace demo erläutert.

• Wenn Sie einen GKE-Cluster mit installiertem Anthos Service Mesh haben, aber das Beispiel benötigen, rufen Sie Online Boutique auf. Darin wird die Bereitstellung des Beispiels im Namespace demo erläutert.

Auf Online Boutique zugreifen

1. Legen Sie den aktuellen Kontext für kubectl auf dem Cluster fest, in dem Sie Online Boutique bereitgestellt haben:

   gcloud container clusters get-credentials CLUSTER_NAME  \
       --project=PROJECT_ID \
       --zone=CLUSTER_LOCATION
   

2. Liste der Online Boutique-Dienste:

   kubectl get services -n demo
   

   Beachten Sie, dass frontend-external ein LoadBalancer ist und eine externe IP-Adresse hat. Die Beispielanwendung enthält einen Dienst, der ein Load-Balancer ist, sodass er in GKE ohne Anthos Service Mesh bereitgestellt werden kann.

3. Rufen Sie die Anwendung in Ihrem Browser mit der externen IP-Adresse des Dienstes frontend-external auf:

   http://FRONTEND_EXTERNAL_IP/
   

4. Anthos Service Mesh bietet ein Standard-Ingress-Gateway namens istio-ingressgateway. Sie können auch über die externe IP-Adresse von istio-ingressgateway auf die Online Boutique zugreifen. Rufen Sie die externe IP-Adresse von istio-ingressgateway ab:

   kubectl get service istio-ingressgateway -n istio-system
   

5. Öffnen Sie einen weiteren Tab in Ihrem Browser und rufen Sie die Anwendung mit der externen IP-Adresse des istio-ingressgateway auf:

   http://INGRESS_GATEWAY_EXTERNAL_IP/
   

6. Führen Sie den folgenden Befehl aus, um curl für den frontend-Dienst mit einfachem HTTP aus einem anderen Pod im Namespace demo auszuführen.

   kubectl exec \
     $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
     -c istio-proxy -n demo -- \
     curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
   

   Ihre Anfrage ist mit dem Status 200 erfolgreich, da standardmäßig sowohl TLS- als auch Klartext-Traffic akzeptiert wird.

Gegenseitiges TLS pro Namespace aktivieren

Für mTLS wenden Sie eine PeerAuthentication-Richtlinie mit kubectl an.

1. Wenden Sie die folgende Authentifizierungsrichtlinie an, um alle Dienste im Namespace demo so zu konfigurieren, dass sie nur mTLS akzeptieren:

   kubectl apply -f - <<EOF
   apiVersion: "security.istio.io/v1beta1"
   kind: "PeerAuthentication"
   metadata:
     name: "namespace-policy"
     namespace: "demo"
   spec:
     mtls:
       mode: STRICT
   EOF
   

   Erwartete Ausgabe:

   peerauthentication.security.istio.io/namespace-policy created

   Die Zeile mode: STRICT in der YAML-Datei konfiguriert die Dienste so, dass sie nur mTLS akzeptieren. mode ist standardmäßig auf PERMISSIVE gesetzt. Damit werden Dienste so konfiguriert, dass sie sowohl Klartext als auch mTLS akzeptieren.

2. Wechseln Sie in Ihrem Browser zu dem Tab, der über die externe IP-Adresse des frontend-external-Dienstes auf die Online Boutique zugreift, und aktualisieren Sie die Seite. Der Browser zeigt den folgenden Fehler an:

   

   Durch das Aktualisieren der Seite wird Klartext an den frontend-Dienst gesendet. Aufgrund der STRICT-Authentifizierungsrichtlinie blockiert der Sidecar-Proxy die Anfrage an den Dienst.

3. Wechseln Sie in Ihrem Browser zu dem Tab, der über die externe IP-Adresse des istio-ingressgateway auf die Online Boutique zugreift, und aktualisieren Sie die Seite, die erfolgreich angezeigt wird. Wenn Sie mithilfe des istio-ingressgateway auf Online Boutique zugreifen, verwendet die Anfrage den folgenden Pfad:

   

   mTLS-Authentifizierungsablauf:

   1. Der Browser sendet eine Klartext-HTTP-Anfrage an den Server.
   2. Der istio-ingressgateway-Proxy-Container fängt die Anfrage ab.
   3. Der istio-ingressgateway-Proxy führt einen TLS-Handshake mit dem serverseitigen Proxy aus (in diesem Beispiel der Frontend-Dienst). Dieser Handshake umfasst einen Austausch von Zertifikaten. Diese Zertifikate werden von Anthos Service Mesh vorab in die Proxy-Container geladen.
   4. Der istio-ingressgateway-Proxy führt eine sichere Namensprüfung für das Serverzertifikat durch und bestätigt so, dass der Server über eine autorisierte Identität ausgeführt wird.
   5. Die istio-ingressgateway- und Serverproxys stellen eine gegenseitige TLS-Verbindung her und der Serverproxy leitet die Anfrage an den Server des Anwendungscontainers (den Frontend-Dienst) weiter.

4. Führen Sie den folgenden Befehl aus, um curl für den frontend-Dienst mit einfachem HTTP aus einem anderen Pod im Namespace demo auszuführen.

   kubectl exec \
     $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
     -c istio-proxy -n demo -- \
     curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
   

   Ihre Anfrage schlägt fehl, weil alle Dienste im demo-Namespace auf STRICT mTLS sind festgelegt und der Sidecar-Proxy die Anfrage an den Dienst blockiert.

   Erwartete Ausgabe:

   000
   command terminated with exit code 56

mTLS-Status aufrufen

Sie können den Status von Anthos-Sicherheitsfeatures, einschließlich Authentifizierungsrichtlinien, in der Google Cloud Console ansehen.

1. Rufen Sie in der Google Cloud Console die Seite GKE Enterprise-Sicherheit auf.

   Zur GKE Enterprise-Sicherheit

2. Wählen Sie das Google Cloud-Projekt aus der Drop-down-Liste in der Menüleiste aus.

   Die Richtlinienzusammenfassung zeigt den Status der Anwendungssicherheit einschließlich mTLS an.

3. Klicken Sie auf Richtlinienprüfung, um den Status der Arbeitslastrichtlinien für jeden Cluster und Namespace aufzurufen. Einen Überblick finden Sie auf der Karte mTLS-Status. Die Liste Arbeitslasten enthält den mTLS-Status der einzelnen Arbeitslasten.

   

Authentifizierungsrichtlinien suchen und löschen

1. Eine Liste aller PeerAuthentication-Richtlinien im Service Mesh:

   kubectl get peerauthentication --all-namespaces
   

2. Löschen Sie die Authentifizierungsrichtlinie:

   kubectl delete peerauthentication -n demo namespace-policy
   

   Erwartete Ausgabe:

   peerauthentication.security.istio.io "namespace-policy" deleted

3. Greifen Sie über die externe IP-Adresse des Dienstes frontend-external auf die Online Boutique zu und aktualisieren Sie die Seite. Die Seite wird wie erwartet angezeigt.

4. Führen Sie den folgenden Befehl aus, um curl für den frontend-Dienst mit einfachem HTTP aus einem anderen Pod im Namespace demo auszuführen.

   kubectl exec \
     $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
     -c istio-proxy -n demo -- \
     curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
   

   Ihre Anfrage ist mit dem Status 200 erfolgreich, da standardmäßig sowohl TLS- als auch Klartext-Traffic akzeptiert wird.

Wenn Sie die Seite in der Google Cloud Console aktualisieren, auf der die Liste Arbeitslasten angezeigt wird, lautet der mTLS-Status jetzt Permissive.

Gegenseitiges TLS pro Arbeitslast aktivieren

Zum Festlegen einer PeerAuthentication-Richtlinie für eine bestimmte Arbeitslast müssen Sie den Abschnitt selector konfigurieren und die Labels angeben, die der gewünschten Arbeitslast entsprechen. Anthos Service Mesh kann jedoch keine Richtlinien für Arbeitslast für ausgehenden mTLS-Traffic zu einem Dienst zusammenfassen. Sie müssen eine Zielregel konfigurieren, um dieses Verhalten zu verwalten.

1. Wenden Sie eine Authentifizierungsrichtlinie auf eine bestimmte Arbeitslast im Namespace demo an: Beachten Sie, wie die folgende Richtlinie Labels und Selektoren verwendet, um die jeweilige frontend-Bereitstellung anzusteuern.

   cat <<EOF | kubectl apply -n demo -f -
   apiVersion: "security.istio.io/v1beta1"
   kind: "PeerAuthentication"
   metadata:
     name: "frontend"
     namespace: "demo"
   spec:
     selector:
       matchLabels:
         app: frontend
     mtls:
       mode: STRICT
   EOF
   

   Erwartete Ausgabe:

   peerauthentication.security.istio.io/frontend created

2. Konfigurieren Sie eine übereinstimmende Zielregel:

   cat <<EOF | kubectl apply -n demo -f -
   apiVersion: "networking.istio.io/v1alpha3"
   kind: "DestinationRule"
   metadata:
     name: "frontend"
   spec:
     host: "frontend.demo.svc.cluster.local"
     trafficPolicy:
       tls:
         mode: ISTIO_MUTUAL
   EOF
   

   Erwartete Ausgabe:

   destinationrule.networking.istio.io/frontend created

3. Greifen Sie über die externe IP-Adresse des Dienstes frontend-external auf die Online Boutique zu und aktualisieren Sie die Seite. Die Seite wird nicht angezeigt, weil der frontend service auf STRICT mTLS gesetzt ist und der Sidecar-Proxy die Anfrage blockiert.

4. Führen Sie den folgenden Befehl aus, um curl für den frontend-Dienst mit einfachem HTTP aus einem anderen Pod im Namespace demo auszuführen.

   kubectl exec \
     $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
     -c istio-proxy -n demo -- \
     curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
   

   Ihre Anfrage schlägt mit dem Statuscode 56 fehl.

   Wenn Sie die Seite in der Google Cloud Console aktualisieren, auf der die Liste Arbeitslasten angezeigt wird, lautet der mTLS-Status für den Dienst frontend jetzt Strict und alle anderen Dienste sind auf Permissive eingestellt.

   

5. Löschen Sie die Authentifizierungsrichtlinie und die Zielregel:

   kubectl delete peerauthentication -n demo frontend
   kubectl delete destinationrule -n demo frontend
   

Mesh-weites mTLS erzwingen

Wenn Sie verhindern möchten, dass alle Dienste im Mesh-Netzwerk Klartext-Traffic akzeptieren, legen Sie eine Mesh-weite PeerAuthentication-Richtlinie mit dem mTLS-Modus auf STRICT fest. Die Mesh-weite PeerAuthentication-Richtlinie sollte keinen Selektor haben und muss im Stamm-Namespace istio-system angewendet werden. Wenn Sie die Richtlinie bereitstellen, stellt die Steuerungsebene automatisch TLS-Zertifikate bereit, sodass Arbeitslasten sich gegenseitig authentifizieren können.

1. Mesh-weites mTLS erzwingen:

   kubectl apply -f - <<EOF
   apiVersion: "security.istio.io/v1beta1"
   kind: "PeerAuthentication"
   metadata:
     name: "mesh-wide"
     namespace: "istio-system"
   spec:
     mtls:
       mode: STRICT
   EOF
   

   Erwartete Ausgabe:

   peerauthentication.security.istio.io/mesh-wide created

2. Greifen Sie über die externe IP-Adresse des Dienstes frontend-external auf die Online Boutique zu und aktualisieren Sie die Seite. Die Seite wird nicht angezeigt.

3. Führen Sie den folgenden Befehl aus, um curl für den frontend-Dienst mit einfachem HTTP aus einem anderen Pod im Namespace demo auszuführen.

   kubectl exec \
     $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
     -c istio-proxy -n demo -- \
     curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
   

   Ihre Anfrage schlägt mit dem Statuscode 56 fehl.

4. Löschen Sie die mesh-wide-Richtlinie:

   kubectl delete peerauthentication -n istio-system mesh-wide
   

Wenn Sie die Seite in der Google Cloud Console aktualisieren, sehen Sie, dass in den mTLS-Details für alle Dienste jetzt Permissive angezeigt wird.

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder Sie behalten das Projekt und löschen die einzelnen Ressourcen.

• Wenn Sie zusätzliche Gebühren vermeiden möchten, löschen Sie den Cluster:

  gcloud container clusters delete  CLUSTER_NAME  \
      --project=PROJECT_ID \
      --zone=CLUSTER_LOCATION
  

• Wenn Sie den Cluster behalten und das Online Boutique-Beispiel entfernen möchten:

  kubectl delete namespaces demo
  

Nächste Schritte

• Eine allgemeine Anleitung zum Konfigurieren von PeerAuthentication-Richtlinien finden Sie unter Transportsicherheit konfigurieren.