Anthos Service Mesh und Traffic Director heißen jetzt Cloud Service Mesh. Weitere Informationen finden Sie in der Cloud Service Mesh-Übersicht.

Diese Seite wurde von der Cloud Translation API übersetzt.

Cloud Service Mesh am Beispiel: Autorisierung

In dieser Anleitung erfahren Sie, was Autorisierung ist und wie Sie sie mit Cloud Service Mesh für eine Beispielanwendung aktivieren, um zu lernen, wie Sie Autorisierungsrichtlinien für Ihre Mikrodienste aktivieren. Sie erstellen ein AuthorizationPolicy, um DENY auf einen Mikrodienst zuzugreifen, und dann ein AuthorizationPolicy, um ALLOW auf einen Mikrodienst zuzugreifen.

Was ist die Autorisierung?

Bei der Authentifizierung wird eine Identität überprüft: Ist dieser Dienst der, für den er sich ausgibt? Bei der Autorisierung wird die Berechtigung geprüft: Darf dieser Dienst das tun? Identität ist für diese Idee von grundlegender Bedeutung. Mit Cloud Service Mesh können Sie die Kommunikation zwischen Arbeitslasten in Ihrem Mesh-Netzwerk steuern, um die Sicherheit und den Zugriff zu verbessern.AuthorizationPolicies

In einer Mikrodienstarchitektur, in der Aufrufe über Netzwerkbegrenzungen hinweg erfolgen, sind IP-basierte Firewallregeln oft nicht ausreichend, um den Zugriff zwischen Arbeitslasten zu sichern. Mit Cloud Service Mesh können Sie Autorisierungsregeln für folgende Zwecke festlegen:

Zugriff auf Arbeitslasten in Ihrem Mesh steuern, entweder von Arbeitslast zu Arbeitslast oder von Endnutzer zu Arbeitslast
Sie können Richtlinien je nach Bedarf allgemein oder detailliert definieren.

Eine ausführliche Erläuterung zur Konfiguration von Richtlinien und Best Practices finden Sie unter Autorisierung mit Cloud Service Mesh.

Ingress-Gateway bereitstellen

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 
```
Erstellen Sie einen Namespace für Ihr Ingress-Gateway:
```
kubectl create namespace asm-ingress
```
Aktivieren Sie den Namespace für die Injection: Die Schritte hängen von Ihrer Implementierung der Steuerungsebene ab.
Verwaltet (TD)
So wenden Sie das Standard-Injektionslabel auf einen 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
```
Wenn Sie ein vorhandener Nutzer mit der verwalteten Istiod-Steuerungsebene sind:Wir empfehlen die Verwendung der Standardeinfügung, aber die revisionsbasierte Einfügung wird unterstützt. Gehen Sie dazu so vor:
1. Verwenden Sie folgenden Befehl, um die verfügbaren Release-Kanäle 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 Überarbeitungen der Steuerungsebene angezeigt werden, entfernen Sie eine. Mehrere Steuerungsebenenkanäle im Cluster werden nicht unterstützt.
  
  In der Ausgabe ist der Wert in der Spalte NAME das Überarbeitungslabel, das dem verfügbaren Release-Kanal für die Cloud Service Mesh-Version entspricht.
2. Wenden Sie das Überarbeitungslabel auf den Namespace an.
  kubectl label namespace asm-ingress \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
Clusterintern
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
```
Wir empfehlen die Verwendung der Standardinjektion, aber auch die revisionsbasierte Injektion wird unterstützt. Folgen Sie dieser Anleitung:
1. Verwenden Sie den folgenden Befehl, um das Überarbeitungslabel für istiod zu finden:
  kubectl get deploy -n istio-system -l app=istiod -o \ jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
2. Wenden Sie das Überarbeitungslabel auf den Namespace an. Im folgenden Befehl ist REVISION_LABEL der Wert des Überarbeitungslabels istiod, den Sie im vorherigen Schritt notiert haben.
  kubectl label namespace asm-ingress \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite

Stellen Sie das Beispiel-Gateway im anthos-service-mesh-samples-Repository 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 Online Boutique bereitstellen

Falls noch nicht geschehen, 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

Erstellen Sie den Namespace für die Beispielanwendung:
```
kubectl create namespace onlineboutique
```
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.
Stellen Sie die Beispielanwendung, die 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

Rufen Sie die Pods im Namespace onlineboutique auf:

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.

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

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

„DenyAll“-Autorisierung für eine Arbeitslast

In diesem Abschnitt wird ein AuthorizationPolicy hinzugefügt, um den gesamten eingehenden Traffic an den Währungsdienst zu blockieren. AuthorizationPolicies transformieren AuthorizationPolicies in von Envoy lesbare Konfigurationen und wenden die Konfigurationen auf Ihre Sidecar-Proxys an. Dadurch kann der Envoy-Proxy eingehende Anfragen an einen Dienst autorisieren oder ablehnen.

Wenden Sie eine AuthorizationPolicy auf die currencyservice an. Beachten Sie den Abgleich (match) für das Label currencyservice in der YAML-Datei.

kubectl apply -f docs/authorization/currency-deny-all.yaml -n onlineboutique

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: currency-policy
spec:
  selector:
    matchLabels:
      app: currencyservice

Versuchen Sie, auf das EXTERNAL-IP Ihres Gateways zuzugreifen, um Online Boutique im Webbrowser aufzurufen. Sie sollten einen Autorisierungsfehler (500 Internal Service Error) von currency service sehen.

Sidecar-Proxy-Logs beobachten

Wenn Sie sehen möchten, was im Sidecar-Proxy passiert, können Sie sich die Logs im Pod ansehen.

Rufen Sie den Namen Ihres currencyservice-Pods ab:

CURRENCY_POD=$(kubectl get pod -n onlineboutique |grep currency|awk '{print $1}')

Legen Sie den Envoy-Proxy so fest, dass Logs auf Trace-Ebene zugelassen werden. Standardmäßig werden blockierte Autorisierungsaufrufe nicht protokolliert:
```
kubectl debug --image istio/base --target istio-proxy -it $CURRENCY_POD -n onlineboutique -- curl -X POST "http://localhost:15000/logging?level=trace"
```
Erwartete Ausgabe: none {:.devsite-disable-click-to-copy} active loggers: admin: trace alternate_protocols_cache: trace ... tracing: trace upstream: trace udp: trace wasm: trace
Verwenden Sie curl, um Traffic an Ihre EXTERNAL_IP zu senden und Logs zu generieren:
```
for i in {0..10}; do
curl -s -I $FRONTEND_IP ; done
```

Sehen Sie sich die Logs zur rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) in Ihrem istio-proxy an:

kubectl logs -n onlineboutique $CURRENCY_POD -c istio-proxy | grep -m5 rbac

Erwartete Ausgabe:

2022-07-08T14:19:20.442920Z     debug   envoy rbac      checking request: requestedServerName: outbound_.7000_._.currencyservice.onlineboutique.svc.cluster.local, sourceIP: 10.8.8.5:34080, directRemoteIP: 10.8.8.5:34080, remoteIP: 10.8.8.5:34080,localAddress: 10.8.0.6:7000, ssl: uriSanPeerCertificate: spiffe://christineskim-tf-asm.svc.id.goog/ns/onlineboutique/sa/default, dnsSanPeerCertificate: , subjectPeerCertificate: OU=istio_v1_cloud_workload,O=Google LLC,L=Mountain View,ST=California,C=US, headers: ':method', 'POST'
2022-07-08T14:19:20.442944Z     debug   envoy rbac      enforced denied, matched policy none
2022-07-08T14:19:20.442965Z     debug   envoy http      [C73987][S13078781800499437460] Sending local reply with details rbac_access_denied_matched_policy[none]
  ```

In den Logs sollte die Meldung enforced denied angezeigt werden, die besagt, dass currencyservice so festgelegt ist, dass eingehende Anfragen blockiert werden.

Eingeschränkten Zugriff zulassen

Anstelle einer DENYALL-Richtlinie können Sie den Zugriff für bestimmte Arbeitslasten zulassen. Dies ist in einer Mikrodienstarchitektur relevant, in der Sie sicherstellen möchten, dass nur autorisierte Dienste miteinander kommunizieren können.

In diesem Abschnitt aktivieren Sie die Kommunikation zwischen den Diensten frontend und checkout und dem Dienst currency.

In der folgenden Datei ist zu sehen, dass ein bestimmter source.principal(Client) auf currencyservice zugreifen darf:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: currency-policy
spec:
  selector:
    matchLabels:
      app: currencyservice
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/onlineboutique/sa/frontend"]
  - from:
    - source:
        principals: ["cluster.local/ns/onlineboutique/sa/checkoutservice"]

Wenden Sie die Richtlinie an:

kubectl apply -f docs/authorization/currency-allow-frontend-checkout.yaml -n onlineboutique

Rufen Sie EXTERNAL-IP in Ihrem Webbrowser auf. Sie sollten jetzt auf Online Boutique zugreifen können.

Cloud Service Mesh am Beispiel: Autorisierung

Was ist die Autorisierung?

Ingress-Gateway bereitstellen

Verwaltet (TD)

Verwaltet (Istiod)

Clusterintern

Beispielanwendung Online Boutique bereitstellen

Dienste ansehen

„DenyAll“-Autorisierung für eine Arbeitslast

Sidecar-Proxy-Logs beobachten

Eingeschränkten Zugriff zulassen