Cloud Service Mesh am Beispiel: mTLS

Hinweis: Diese Anleitung gilt nur für Cloud Service Mesh mit Istio APIs und nicht für Google Cloud APIs. Weitere Informationen finden Sie unter Cloud Service Mesh – Übersicht.

In Cloud 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 Cloud Service Mesh können Sie mTLS außerhalb Ihres Anwendungscodes durch Anwenden einer einzelnen YAML-Datei erzwingen. Cloud 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
• Cloud Service Mesh

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen.

Neuen Nutzern von Google Cloud 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

• Achten Sie darauf, dass die Abrechnung für Ihr Projekt aktiviert ist.

• Cloud Service Mesh auf einem GKE-Cluster bereitstellen. Es gibt verschiedene unterstützte Einrichtungsmethoden:

  • Fleet API und eine verwaltete Steuerungsebene auf Google Cloud

  • asmcli und eine nicht verwaltete, clusterinterne Steuerungsebene Google Cloud

• Klonen Sie das Repository:

  git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-samples
  cd anthos-service-mesh-samples
  

Ingress-Gateway bereitstellen

1. Legen Sie den aktuellen Kontext für kubectl auf den Cluster fest:

   Hinweis: Verwenden Sie --region anstelle von --zone, wenn der Cluster ein regionaler Cluster ist.

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

2. Erstellen Sie einen Namespace für Ihr Ingress-Gateway:

   kubectl create namespace asm-ingress
   

3. Aktivieren Sie den Namespace für die Injektion. Die Schritte hängen von Ihrer Implementierung der Steuerungsebene ab.

   Verwaltet (TD)

   Wenden Sie das Standard-Einschleusungslabel auf den Namespace an.

   kubectl label namespace asm-ingress \
       istio.io/rev- istio-injection=enabled --overwrite
   

   Verwaltet (Istiod)

   Empfohlen: Führen Sie den folgenden Befehl aus, um das Standard-Injektionslabel auf den Namespace anzuwenden:

     kubectl label namespace asm-ingress \
         istio.io/rev- istio-injection=enabled --overwrite
   

   Für vorhandene Nutzer der verwalteten Istiod-Steuerungsebene: Wir empfehlen die Verwendung der Standardeinschleusung. Die versionsbasierte Einschleusung wird jedoch auch unterstützt. Gehen Sie so vor:

   1. Führen Sie folgenden Befehl aus, um die verfügbaren Release-Versionen zu finden:

      kubectl -n istio-system get controlplanerevision
      

      Die Ausgabe sieht etwa so aus:

      NAME                AGE
      asm-managed-rapid   6d7h
      

      Hinweis: Wenn in der vorherigen Liste zwei Revisionen der Steuerungsebene angezeigt werden, entfernen Sie eine. Mehrere Steuerungsebenenversionen im Cluster werden nicht unterstützt.

      In der Ausgabe ist der Wert in der Spalte NAME das Versionslabel für die verfügbare Release-Version der Cloud Service Mesh-Version.

   2. Wenden Sie das Versionslabel auf den Namespace an.

      kubectl label namespace asm-ingress \
          istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      

4. Stellen Sie das Beispiel-Gateway im Repository anthos-service-mesh-samples bereit:

   kubectl apply -n asm-ingress \
   -f docs/shared/asm-ingress-gateway
   

   Erwartete Ausgabe:

   serviceaccount/asm-ingressgateway configured
   service/asm-ingressgateway configured
   deployment.apps/asm-ingressgateway configured
   gateway.networking.istio.io/asm-ingressgateway configured
   

Beispielanwendung für Online-Boutique bereitstellen

1. Falls nicht, legen Sie den aktuellen Kontext für kubectl auf den Cluster fest:

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

2. Erstellen Sie den Namespace für die Beispielanwendung:

     kubectl create namespace onlineboutique
   

3. Fügen Sie dem Namespace onlineboutique ein Label hinzu, um Envoy-Proxys automatisch einzufügen. Folgen Sie den Schritten zum Aktivieren der automatischen Sidecar-Einfügung.

4. Stellen Sie die Beispielanwendung, VirtualService für das Frontend und Dienstkonten für die Arbeitslasten bereit. In dieser Anleitung stellen Sie die Mikrodienst-Demo-Anwendung "Online Boutique" bereit.

     kubectl apply \
     -n onlineboutique \
     -f docs/shared/online-boutique/virtual-service.yaml
     kubectl apply \
     -n onlineboutique \
     -f docs/shared/online-boutique/service-accounts
   

Dienste ansehen

1. Sehen Sie sich die Pods im Namespace onlineboutique an:

   kubectl get pods -n onlineboutique
   

   Erwartete Ausgabe:

   NAME                                     READY   STATUS    RESTARTS   AGE
   adservice-85598d856b-m84m6               2/2     Running   0          2m7s
   cartservice-c77f6b866-m67vd              2/2     Running   0          2m8s
   checkoutservice-654c47f4b6-hqtqr         2/2     Running   0          2m10s
   currencyservice-59bc889674-jhk8z         2/2     Running   0          2m8s
   emailservice-5b9fff7cb8-8nqwz            2/2     Running   0          2m10s
   frontend-77b88cc7cb-mr4rp                2/2     Running   0          2m9s
   loadgenerator-6958f5bc8b-55q7w           2/2     Running   0          2m8s
   paymentservice-68dd9755bb-2jmb7          2/2     Running   0          2m9s
   productcatalogservice-84f95c95ff-c5kl6   2/2     Running   0          114s
   recommendationservice-64dc9dfbc8-xfs2t   2/2     Running   0          2m9s
   redis-cart-5b569cd47-cc2qd               2/2     Running   0          2m7s
   shippingservice-5488d5b6cb-lfhtt         2/2     Running   0          2m7s
   

   Alle Pods für Ihre Anwendung sollten mit dem Wert 2/2 in der Spalte READY ausgeführt werden. Dieser Wert weist darauf hin, dass die Pods einen Envoy-Sidecar-Proxy erfolgreich eingefügt haben. Wenn 2/2 nach einigen Minuten nicht angezeigt wird, lesen Sie die Anleitung zur Fehlerbehebung.

2. Rufen Sie die externe IP-Adresse ab und legen Sie sie auf eine Variable fest:

   kubectl get services -n asm-ingress
   export FRONTEND_IP=$(kubectl --namespace asm-ingress \
   get service --output jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}' \
   )
   

   Die Ausgabe sollte in etwa so aussehen:

   NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                      AGE
   asm-ingressgateway   LoadBalancer   10.19.247.233   35.239.7.64   80:31380/TCP,443:31390/TCP,31400:31400/TCP   27m
   
   

3. Rufen Sie die Adresse EXTERNAL-IP in Ihrem Webbrowser auf. Sie sollten den Online Boutique-Shop in Ihrem Browser sehen.

   

TestCurl-Pod erstellen

Erstellen Sie einen TestCurl-Pod, um Test-Traffic im Klartext zu senden.

  apiVersion: v1
  kind: Pod
  metadata:
    name: testcurl
    namespace: default
    annotations:
      sidecar.istio.io/inject: "false"
  spec:
    containers:
    - name: curl
      image: curlimages/curl
      command: ["sleep", "600"]

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. Listen Sie die Dienste im Namespace frontend auf:

   kubectl get services -n frontend
   

   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 Cloud 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. Cloud Service Mesh bietet Ihnen die Möglichkeit, ein Ingress-Gateway bereitzustellen. Sie können auf die Online-Boutique auch mit der externen IP-Adresse des Ingress-Gateways zugreifen. Rufen Sie die externe IP-Adresse der Anwendung ab: Ersetzen Sie die Platzhalter durch die folgenden Informationen:

   • GATEWAY_SERVICE_NAME ist der Name des Ingress-Gateway-Dienstes. Wenn Sie das Beispielgateway ohne Änderung bereitgestellt oder das Standardgateway für eingehenden Traffic bereitgestellt haben, lautet der Name istio-ingressgateway.
   • GATEWAY_NAMESPACE ist der Namespace, in dem Sie das Ingress-Gateway bereitgestellt haben. Wenn Sie das Standard-Gateway für eingehenden Traffic bereitgestellt haben, lautet der Namespace istio-system.

   kubectl get service GATEWAY_NAME -n GATEWAY_NAMESPACE
   

5. Öffnen Sie einen weiteren Tab in Ihrem Browser und rufen Sie die Anwendung mithilfe der externen IP-Adresse des Ingress-Gateways auf:

   http://INGRESS_GATEWAY_EXTERNAL_IP/
   

6. Führen Sie den folgenden Befehl aus, um curl für den frontend-Dienst mit reinem HTTP aus einem anderen Pod durchzuführen. Da sich die Dienste in verschiedenen Namespaces befinden, müssen Sie „curl“ für den DNS-Namen des Dienstes frontend durchführen.

   kubectl debug --image istio/base --target istio-proxy -it \
     $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \
     -n product-catalog -- \
     curl http://frontend.frontend.svc.cluster.local: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. Speichern Sie die folgende Authentifizierungsrichtlinie als mtls-namespace.yaml.

   cat <<EOF > mtls-namespace.yaml
   apiVersion: "security.istio.io/v1beta1"
   kind: "PeerAuthentication"
   metadata:
     name: "namespace-policy"
   spec:
     mtls:
       mode: STRICT
   EOF
   

   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. Wenden Sie die Authentifizierungsrichtlinie an, um alle Online Boutique-Dienste so zu konfigurieren, dass sie nur mTLS akzeptieren:

   for ns in ad cart checkout currency email frontend loadgenerator \
        payment product-catalog recommendation shipping; do
   kubectl apply -n $ns -f mtls-namespace.yaml
   done
   

   Erwartete Ausgabe:

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

3. Öffnen Sie in Ihrem Browser den Tab, der über die externe IP-Adresse des Dienstes frontend-external auf die Online-Boutique zugreift:

   http://FRONTEND_EXTERNAL_IP/
   

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

5. 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 über das Ingress-Gateway auf die Online Boutique zugreifen, verwendet die Anfrage den folgenden Pfad:

   

   mTLS-Authentifizierungsablauf:

   1. Der Browser sendet eine Klartext-HTTP-Anfrage an den Server.
   2. Der Ingress-Gateway-Proxy-Container fängt die Anfrage ab.
   3. Der Ingress-Gateway-Proxy führt einen TLS-Handshake mit dem serverseitigen Proxy aus (in diesem Beispiel den Frontend-Dienst). Dieser Handshake umfasst einen Austausch von Zertifikaten. Diese Zertifikate werden von Cloud Service Mesh vorab in die Proxy-Container geladen.
   4. Der Ingress-Gateway-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 Ingress-Gateway- und Serverproxys stellen eine gegenseitige TLS-Verbindung her und der Serverproxy leitet die Anfrage an den Server des Anwendungscontainers (den Frontend-Dienst) weiter.

6. Führen Sie den folgenden Befehl aus, um curl für den frontend-Dienst mit reinem HTTP aus einem anderen Pod durchzuführen.

   kubectl exec testcurl -n default -- curl \
     http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
   

   Ihre Anfrage schlägt fehl, da wir Nur-Text-Traffic von einer Sidecar-losen Arbeitslast senden, auf die die STRICT-Richtlinie peerAuthentication angewendet wird.

Authentifizierungsrichtlinien suchen und löschen

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

   kubectl get peerauthentication --all-namespaces
   

   Die Ausgabe sieht etwa so aus:

   NAMESPACE         NAME               MODE     AGE
   ad                namespace-policy   STRICT   17m
   cart              namespace-policy   STRICT   17m
   checkout          namespace-policy   STRICT   17m
   currency          namespace-policy   STRICT   17m
   email             namespace-policy   STRICT   17m
   frontend          namespace-policy   STRICT   17m
   loadgenerator     namespace-policy   STRICT   17m
   payment           namespace-policy   STRICT   17m
   product-catalog   namespace-policy   STRICT   17m
   recommendation    namespace-policy   STRICT   17m
   shipping          namespace-policy   STRICT   17m
   

2. Löschen Sie die Authentifizierungsrichtlinie aus allen Namespaces für Online Boutique:

   for ns in ad cart checkout currency email frontend loadgenerator payment \
     product-catalog recommendation shipping; do
       kubectl delete peerauthentication -n $ns namespace-policy
   done;
   

   Erwartete Ausgabe:

   peerauthentication.security.istio.io "namespace-policy" deleted
   peerauthentication.security.istio.io "namespace-policy" deleted
   peerauthentication.security.istio.io "namespace-policy" deleted
   peerauthentication.security.istio.io "namespace-policy" deleted
   peerauthentication.security.istio.io "namespace-policy" deleted
   peerauthentication.security.istio.io "namespace-policy" deleted
   peerauthentication.security.istio.io "namespace-policy" deleted
   peerauthentication.security.istio.io "namespace-policy" deleted
   peerauthentication.security.istio.io "namespace-policy" deleted
   peerauthentication.security.istio.io "namespace-policy" deleted
   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 reinem HTTP aus einem anderen Pod durchzuführen.

   kubectl debug --image istio/base --target istio-proxy -it \
     $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \
     -n product-catalog -- \
     curl http://frontend.frontend.svc.cluster.local: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 in der Google Cloud -Konsole die Seite mit der Liste Arbeitslasten aktualisieren, sehen Sie jetzt, dass der mTLS-Status mit Permissive angezeigt wird.

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. Cloud 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 an. Beachten Sie, wie die folgende Richtlinie Labels und Selektoren verwendet, um die jeweilige frontend-Bereitstellung anzusteuern.

   cat <<EOF | kubectl apply -n frontend -f -
   apiVersion: "security.istio.io/v1beta1"
   kind: "PeerAuthentication"
   metadata:
     name: "frontend"
     namespace: "frontend"
   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 frontend -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 reinem HTTP aus einem anderen Pod durchzuführen.

   kubectl exec testcurl -n default -- curl \
     http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
   

   Ihre Anfrage schlägt fehl, da wir Nur-Text-Traffic von einer Sidecar-losen Arbeitslast senden, auf die die STRICT-Richtlinie peerAuthentication angewendet wird.

5. Löschen Sie die Authentifizierungsrichtlinie:

   kubectl delete peerauthentication -n frontend frontend
   

   Erwartete Ausgabe:

   peerauthentication.security.istio.io "frontend" deleted
   

6. Löschen Sie die Zielregel:

   kubectl delete destinationrule -n frontend frontend
   

   Erwartete Ausgabe:

   destinationrule.networking.istio.io "frontend" deleted
   

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 reinem HTTP aus einem anderen Pod durchzuführen.

   kubectl exec testcurl -n default -- curl \
     http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
   

   Ihre Anfrage schlägt fehl, da wir Nur-Text-Traffic von einer Sidecar-losen Arbeitslast senden, auf die die STRICT-Richtlinie peerAuthentication angewendet wird.

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

   kubectl delete peerauthentication -n istio-system mesh-wide
   

   Erwartete Ausgabe:

   peerauthentication.security.istio.io "mesh-wide" deleted
   

Hinweis :Weitere Informationen zu Autorisierungsrichtlinien finden Sie unter Cloud Service Mesh am Beispiel: Autorisierung.

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:

  1. Löschen Sie die Anwendungs-Namespaces:

    kubectl delete -f online-boutique/kubernetes-manifests/namespaces
  

  Erwartete Ausgabe:

  namespace "ad" deleted
  namespace "cart" deleted
  namespace "checkout" deleted
  namespace "currency" deleted
  namespace "email" deleted
  namespace "frontend" deleted
  namespace "loadgenerator" deleted
  namespace "payment" deleted
  namespace "product-catalog" deleted
  namespace "recommendation" deleted
  namespace "shipping" deleted
  

  1. Löschen Sie die Diensteinträge:

    kubectl delete -f online-boutique/istio-manifests/allow-egress-googleapis.yaml
  

  Erwartete Ausgabe:

  serviceentry.networking.istio.io "allow-egress-googleapis" deleted
  serviceentry.networking.istio.io "allow-egress-google-metadata" deleted
  

Nächste Schritte

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