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" |
Übereinstimmend | Abgelehnt | dry_run_result: "AuthzDenied" dry_run_policy_name: dry_run_policy_rule: |
|
Nur ALLOW -Richtlinie |
Keine Übereinstimmung | Abgelehnt | dry_run_result: "AuthzDenied" |
Ü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 AbfrageNAMESPACE
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 einedeny-path-headers
-Autorisierungsrichtlinie im Namespacefoo
. - 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.