Version 1.20

Verfügbare Versionen

1.20 (aktuell)
1.19
1.18
1.17
1.16
1.15
1.13
1.12
1.12
1.12
1.12

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.

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.

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

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

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.
Rufen Sie die Anwendung in Ihrem Browser mit der externen IP-Adresse des Dienstes frontend-external auf:
```
http://FRONTEND_EXTERNAL_IP/
```
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
```
Ö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/
```
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.

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

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

Zur GKE Enterprise-Sicherheit
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.
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

Eine Liste aller PeerAuthentication-Richtlinien im Service Mesh:
```
kubectl get peerauthentication --all-namespaces
```

Löschen Sie die Authentifizierungsrichtlinie:

kubectl delete peerauthentication -n demo namespace-policy

Erwartete Ausgabe:

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

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

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

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

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.

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

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.