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.

Cloud Service Mesh anhand eines Beispiels: mTLS

In Cloud Service Mesh 1.5 und höher wird automatisches gegenseitiges TLS (auto mTLS) durch Standardeinstellung. 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. Beachten Sie jedoch, dass Dienste akzeptieren Sie 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 erzwingen, indem Sie eine einzelne YAML-Datei anwenden. Cloud Service Mesh bietet Ihnen die Flexibilität, eine Authentifizierungsrichtlinie auf das gesamte Service Mesh, auf einen Namespace oder auf eine einzelne Arbeitslast anzuwenden.

Gegenseitiges mTLS

Kosten

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

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.

Hinweis

Die Abrechnung für das Cloud-Projekt muss aktiviert sein. So prüfen Sie, ob die Abrechnung für Ihr Projekt aktiviert ist.
Cloud Service Mesh in einem GKE-Cluster installieren und Ingress bereitstellen Gateway. Wenn Sie für diese Anleitung einen Cluster einrichten müssen, finden Sie in der Cloud Service Mesh-Kurzanleitung folgende Schritte:
- GKE-Cluster erstellen
- Verwaltetes Cloud Service Mesh bereitstellen.
- Ingress-Gateway bereitstellen.
- Bereitstellung der Beispielanwendung Online Boutique aus dem Repository anthos-service-mesh-packages, die gegenüber dem ursprünglichen Satz von Manifesten in microservices-demo-Repository verändert wurde Gemäß den Best Practices wird jeder Dienst in einem separaten Namespace mit einem eigenen Dienstkonto bereitgestellt.

Auf Online Boutique zugreifen

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

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 Load-Balancer ausführen, sodass er in GKE bereitgestellt werden kann, Cloud Service Mesh.
Rufen Sie die Anwendung in Ihrem Browser mit der externen IP-Adresse des Dienstes frontend-external auf:
```
http://FRONTEND_EXTERNAL_IP/
```
Cloud Service Mesh bietet Ihnen die Möglichkeit, ein Ingress-Gateway bereitzustellen. Sie können Sie können auch über die externe IP-Adresse des Ingress auf Online Boutique zugreifen. Gateway. Rufen Sie die externe IP-Adresse der Anwendung ab: Ersetzen Sie die Platzhalter durch folgende 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
```
Ö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/
```
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 den DNS-Namen des frontend-Dienstes.
```
kubectl exec \
  $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \
  -c istio-proxy -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.

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.

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

Ö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/
```
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.
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.

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 \
  $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \
  -c istio-proxy -n product-catalog -- \
  curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'

Ihre Anfrage schlägt fehl, da alle Online-Boutique-Dienste auf mTLS STRICT gesetzt sind 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 GKE Enterprise-Sicherheitsfunktionen aufrufen, darunter: Authentifizierungsrichtlinien in der Google Cloud Console.

Rufen Sie in der Google Cloud Console die Seite Übersicht von GKE Enterprise auf.

Zur Übersicht
Wählen Sie das Google Cloud-Projekt aus der Projektliste in der Menüleiste aus.
Klicken Sie auf der Karte „Richtlinienstatus“ je nach Konfiguration auf Richtlinie ansehen oder Richtlinie aktivieren. Das Policy Controller-Dashboard wird geöffnet.
Klicken Sie auf den Tab Verstöße.
Setzen Sie unter Ressourcentyp ein Häkchen bei Pod. Hier sehen Sie eine Liste der Pods, die gegen eine Richtlinie verstoßen.

Authentifizierungsrichtlinien suchen und löschen

Eine Liste aller PeerAuthentication-Richtlinien im Service Mesh:

kubectl get peerauthentication --all-namespaces

Die Ausgabe sieht in 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

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

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.

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 \
  $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \
  -c istio-proxy -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 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. Cloud Service Mesh kann jedoch keine Richtlinien auf Arbeitslastebene für ausgehende E-Mails aggregieren. mTLS-Traffic zu einem Dienst Sie müssen eine Zielregel konfigurieren, um dieses Verhalten zu verwalten.

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

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

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.
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 \
  $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \
  -c istio-proxy -n product-catalog -- \
  curl http://frontend.frontend.svc.cluster.local: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.

Löschen Sie die Authentifizierungsrichtlinie:

kubectl delete peerauthentication -n frontend frontend

Erwartete Ausgabe:

peerauthentication.security.istio.io "frontend" deleted

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.

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

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.

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 \
  $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \
  -c istio-proxy -n product-catalog -- \
  curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'

Ihre Anfrage schlägt mit dem Statuscode 56 fehl.

Löschen Sie die mesh-wide-Richtlinie:
```
kubectl delete peerauthentication -n istio-system mesh-wide
```
Erwartete Ausgabe:
```
peerauthentication.security.istio.io "mesh-wide" deleted
```
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:

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

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.