Cloud Service Mesh am Beispiel: mTLS

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 ausfü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