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.

Erweiterte Features der Autorisierungsrichtlinie konfigurieren

Die Cloud Service Mesh-Autorisierungsrichtlinie bietet Zugriffssteuerung auf Mesh-Netzwerk-, Namespace- und Arbeitslastebene für Ihre Arbeitslasten im Mesh-Netzwerk. Auf dieser Seite werden Details zum Konfigurieren der erweiterten Features der Cloud Service Mesh-Autorisierungsrichtlinie beschrieben, einschließlich des Probelaufmodus und des Logging der Ablehnung. Bei den auf dieser Seite beschriebenen Features wird davon ausgegangen, dass Sie mit den grundlegenden Konzepten von Autorisierungsrichtlinien vertraut sind, die unter Übersicht über Autorisierungsrichtlinien beschrieben werden.

Probelaufmodus

Die Cloud Service Mesh-Autorisierungsrichtlinie unterstützt den Probelaufmodus, mit dem Sie eine Autorisierungsrichtlinie mit echten Produktions-Traffic testen können, ohne sie zu erzwingen. Im Probelaufmodus können Sie die Auswirkungen einer Autorisierungsrichtlinie vor dem Erzwingen besser verstehen. Dadurch verringert sich das Risiko, dass der Produktions-Traffic durch eine falsche Autorisierungsrichtlinie unterbrochen wird.

Sie verwenden die Annotation "istio.io/dry-run": "true" in der Autorisierungsrichtlinie, um sie in den Probelaufmodus zu versetzen.

Beispiel im Probelaufmodus

Das folgende Beispiel deny-path-headers zeigt eine Richtlinie, bei der die Annotation dry-run auf "true gesetzt ist. Die Autorisierungsrichtlinie lehnt Anfragen an den Pfad headers ab und lässt alle anderen Anfragen zu.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-path-headers
  annotations:
    "istio.io/dry-run": "true"
spec:
  selector:
    matchLabels:
      app: httpbin
  action: DENY
  rules:
  - to:
    - operation:
        paths: ["/headers"]

Wenn Sie eine Autorisierungsrichtlinie im Probelaufmodus anwenden, protokolliert Cloud Service Mesh das Erzwingungsergebnis in Cloud Logging, erzwingt jedoch nicht die Richtlinie. Die Anfrage ist immer zulässig. Sie können im Log-Explorer prüfen, ob die Autorisierungsrichtlinie erwartungsgemäß funktioniert.

Details zum Probelauf-Logging

Nachdem Sie eine Autorisierungsrichtlinie im Probelaufmodus angewendet haben, können Sie sich die Ergebnisse der Richtlinie im Log-Explorer ansehen.

Rufen Sie den Log-Explorer auf. Ersetzen Sie in der folgenden URL PROJECT_ID durch Ihre Projekt-ID:
```
https://console.cloud.google.com/logs/query?project=PROJECT_ID
```
Geben Sie im Feld Query Builder eine Abfrage ein, um die Autorisierungsrichtlinie für den Probelaufmodus zu ermitteln. Ersetzen Sie in der folgenden Abfrage NAMESPACE durch Ihren Namespace:
```
logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver" labels.destination_namespace="NAMESPACE" labels.dry_run_result="AuthzDenied"
```
Klicken Sie auf Abfrage ausführen.
Passen Sie den Zeitraum nach Bedarf an.

Der folgende Screenshot zeigt die Probelauflabels im Traffic-Log im Log-Explorer, nachdem die deny-path-headers-Beispielrichtlinie angewendet wurde:

Der Probelaufmodus unterstützt zusätzlich zu den Istio-Probelaufergebnissen die Autorisierungsrichtlinien ALLOW und DENY. Cloud Service Mesh speichert die Ergebnisse des Trockenlaufs in Cloud Logging in den folgenden Labels:

dry_run_result: Das Probelaufergebnis ist entweder "AuthzAllowed" oder "AuthzDenied".
dry_run_policy_name: Der Namespace und der Name der übereinstimmenden Autorisierungsrichtlinie, die die Probelaufentscheidung trifft.
dry_run_policy_rule: Der Index der übereinstimmenden Autorisierungsrichtlinienregel, die die Probelaufentscheidung trifft.

Die folgende Tabelle zeigt die Details, die für eine Autorisierungsrichtlinie im Probelaufmodus protokolliert werden:

Im Probelaufmodus angewendete Autorisierungsrichtlinie	Übereinstimmungsergebnis	Probelaufergebnis	Cloud Logging
Nur `DENY`-Richtlinie	Keine Übereinstimmung	Zulässig	dry_run_result: "AuthzAllowed"
Nur `DENY`-Richtlinie	Übereinstimmend	Abgelehnt	dry_run_result: "AuthzDenied" dry_run_policy_name: . dry_run_policy_rule:
Nur `ALLOW`-Richtlinie	Keine Übereinstimmung	Abgelehnt	dry_run_result: "AuthzDenied"
Nur `ALLOW`-Richtlinie	Übereinstimmend	Zulässig	dry_run_result: "AuthzAllowed" dry_run_policy_name: . dry_run_policy_rule:
Sowohl die Richtlinie `ALLOW` als auch `DENY`	Jeweils keine Übereinstimmung	Abgelehnt	dry_run_result: "AuthzDenied"
	Nur übereinstimmende `DENY`-Richtlinie	Abgelehnt	dry_run_result: "AuthzDenied" dry_run_policy_name: . dry_run_policy_rule:
	Nur übereinstimmende `ALLOW`-Richtlinie	Zulässig	dry_run_result: "AuthzAllowed" dry_run_policy_name: . dry_run_policy_rule:
	Übereinstimmend mit beiden Richtlinien	Abgelehnt	dry_run_result: "AuthzDenied" dry_run_policy_name: . dry_run_policy_rule:

Wenn Sie dem Probelaufergebnis vertrauen, können Sie den Probelaufmodus mit einem der folgenden Ansätze deaktivieren:

Entfernen Sie die Probelaufannotation vollständig.
Ändern Sie den Wert der Probelaufannotation in false.

Nachdem Sie die Richtlinie mit deaktiviertem Probelaufmodus angewendet haben, erzwingt Cloud Service Mesh die Richtlinie.

Logging der Ablehnung

Die Autorisierungsrichtlinie lehnt eine Anfrage ab, wenn sie gemäß der Richtlinie nicht zulässig ist. Bei HTTP-Protokollen (einschließlich gRPC) wird die Anfrage mit dem Statuscode 403 abgelehnt. Bei Nicht-HTTP-Protokollen wird die Verbindung direkt beendet. Das Traffic-Log von Cloud Logging enthält zusätzliche Informationen, die Aufschluss über den Grund für die Ablehnung von Traffic geben. Das Log zeigt beispielsweise an, wie viele Anfragen von der Autorisierungsrichtlinie abgelehnt wurden, was Ihnen helfen kann festzustellen, welche Richtlinienregel die Ablehnung im Vergleich zu Ablehnungen von der Backend-Anwendung verursacht hat.

Im folgenden Beispiel ist die Annotation dry-run auf "false gesetzt. Wenn Sie die Autorisierungsrichtlinie DENY anwenden, erzwingt Cloud Service Mesh sie.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-path-headers
  annotations:
    "istio.io/dry-run": "false"
spec:
  selector:
    matchLabels:
      app: httpbin
  action: DENY
  rules:
  - to:
    - operation:
        paths: ["/headers"]

Nachdem Sie eine DENY-Autorisierungsrichtlinie angewendet haben, können Sie sich die Ergebnisse der Richtlinie im Log-Explorer ansehen.

Rufen Sie den Log-Explorer auf. Ersetzen Sie in der folgenden URL PROJECT_ID durch Ihre Projekt-ID:
```
https://console.cloud.google.com/logs/query?project=PROJECT_ID
```
Geben Sie im Feld Query Builder eine Abfrage ein, um die DENY-Autorisierungsrichtlinie zu ermitteln. Ersetzen Sie in der folgenden Abfrage NAMESPACE durch Ihren Namespace:
```
logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver" labels.destination_namespace="NAMESPACE" labels.response_details="AuthzDenied"
```
Klicken Sie auf Abfrage ausführen.
Passen Sie den Zeitraum nach Bedarf an.

Der folgende Screenshot zeigt einen Logeintrag im Log-Explorer, nachdem die deny-path-headers-Beispielrichtlinie angewendet wurde, um die Richtlinie zu erzwingen. Ob die Autorisierungsrichtlinie für den Fehler 403 verantwortlich war, sehen Sie an den Labels:

Das Traffic-Log von Log-Explorer enthält die folgenden Labels für die Ablehnung der Autorisierung:

response_details: ist auf "AuthzDenied" festgelegt, wenn die Ablehnung durch eine Autorisierungsrichtlinie verursacht wird.
policy_name: enthält den Namespace und den Namen der DENY-Autorisierungsrichtlinie, die die Ablehnung verursacht. Der Wert hat das Format <Namespace>.<Name>. Beispiel: foo.deny-path-headers steht für eine deny-path-headers-Autorisierungsrichtlinie im Namespace foo.
policy_rule: enthält den Index der Regel innerhalb der Autorisierungsrichtlinie, die die Ablehnung verursacht. 0 bedeutet beispielsweise, dass es um die erste Regel innerhalb der Richtlinie geht.

Nächste Schritte

Eine Liste aller Autorisierungsrichtlinien im Service Mesh:

kubectl get authorizationpolicy --all-namespaces

Wenn eine Autorisierungsrichtlinie in Kraft ist, können Sie sie mit kubectl delete löschen:

kubectl delete authorizationpolicy -n NAMESPACE AUTH_POLICY_NAME

Weitere Informationen zum Abrufen des Traffic-Logs finden Sie unter Auf Logs in Cloud Logging zugreifen.