Audit-Richtlinien für Ihre Dienste konfigurieren
In dieser Anleitung wird nur die Implementierung der Steuerungsebene im Cluster unterstützt.
Mit einer Audit-Richtlinie können Sie den Datenzugriff auf Ihre Dienste in Cloud Service Mesh. Durch diese Überprüfung der Dienste lässt sich feststellen, wer was wann und möglicherweise auch warum ausgeführt hat. Mit einer Audit-Richtlinie können Sie wann ein Audit-Log erstellt wird, sowie den Inhalt der Logs. In dieser Anleitung wird erläutert, wie Sie Cloud Service Mesh installieren, damit Sie eine Audit-Richtlinie verwenden können.
Da Sie die Audit-Logs im Log-Explorer von Cloud Logging in der Google Cloud Console ansehen, werden Audit-Richtlinien nur auf den folgenden Plattformen unterstützt:
- GKE in Google Cloud
- Google Distributed Cloud (nur Software) für VMware
- Google Distributed Cloud (nur Software) für Bare Metal
Eine Audit-Richtlinie erweitert die AuthorizationPolicy durch Hinzufügen einer AUDIT
-Aktion. Sie wirkt sich nur auf den Geltungsbereich der Zielrichtlinie aus. Dieser kann eine Arbeitslast, ein Namespace oder das gesamte Mesh-Netzwerk sein. Die Richtlinien sind ORed
, d. h., eine Anfrage wird in einem Log erfasst, wenn eine Richtlinie dies festlegt. Wenn für eine bestimmte Arbeitslast keine Audit-Richtlinie gilt, wird für sie auch kein Audit-Log generiert.
Im Folgenden ist eine Beispiel-Audit-Richtlinie dargestellt, die den gesamten WRITE-Zugriff auf den Pfad /user/profile/*
in myapi
überprüft:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
namespace: ns1
name: anyname
spec:
selector:
matchLabels:
app: myapi
action: AUDIT
rules:
- to:
- operation:
methods: ["POST", "UPDATE", "DELETE"]
paths: ["/user/profile/*"]
Beschränkungen
- Für das Ausgangsgateway ist kein Audit-Log vorhanden.
- Der Prüfinhalt ist nicht konfigurierbar.
- Derzeit sind die Audit-Logs von Cloud Service Mesh gleich zuverlässig wie normale Zugriffslogs. Wenn beispielsweise ein Arbeitslast-Pod neu gestartet wird, Einige Audit-Logs für die Arbeitslast können verloren gehen, wenn sie nicht beibehalten werden.
Hinweise
Führen Sie die Schritte unter Abhängige Tools installieren und Cluster validieren aus, um Folgendes zu tun:- Erforderliche Tools installieren
asmcli
herunterladen- Clusteradministratorberechtigungen erteilen
- Projekt und Cluster validieren
Gateway-Konfiguration vorbereiten
Mit Cloud Service Mesh haben Sie die Möglichkeit, Gateways als Teil Ihres Service Mesh. Ein Gateway beschreibt einen Load-Balancer, der am Rand des Mesh-Netzwerks arbeitet und eingehende oder ausgehende HTTP/TCP-Verbindungen empfängt. Gateways sind Envoy-Proxys, die Ihnen eine detaillierte Kontrolle über den in das Mesh-Netzwerk eingehenden und ausgehenden Traffic ermöglichen.
asmcli
installiert die istio-ingressgateway
nicht. Wir empfehlen, die Steuerungsebene und die Gateways separat bereitzustellen und zu verwalten. Weitere Informationen finden Sie unter Gateways installieren und aktualisieren.
Cloud Service Mesh-Installation anpassen
Passen Sie die Cloud Service Mesh-Installation an, um eine Audit-Richtlinie zu verwenden:
Installationen
Folgen Sie der Anleitung unter Cloud Service Mesh installieren. Fügen Sie beim Ausführen von
asmcli install
die folgende Option ein:--option audit-authorizationpolicy
Beispiel:
./asmcli install \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --ca mesh_ca \ --output_dir DIR_PATH \ --enable_all \ --option audit-authorizationpolicy
Geben Sie alle anderen Overlay-Dateien an, die Sie zum Konfigurieren von Cloud Service Mesh benötigen.
Schließen Sie die Cloud Service Mesh-Installation ab, um das automatische Einfügen des Sidecar-Proxys für Ihre Arbeitslasten zu aktivieren. Siehe Arbeitslasten bereitstellen und neu bereitstellen.
Upgrades
Befolgen Sie die Schritte in Führen Sie ein Upgrade des Cloud Service Mesh durch. Fügen Sie beim Ausführen von
asmcli install
die folgende Option ein:--option audit-authorizationpolicy
Beispiel:
./asmcli install \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --ca mesh_ca \ --output_dir DIR_PATH \ --enable_all \ --option audit-authorizationpolicy
Geben Sie alle anderen Overlay-Dateien an, die Sie zum Konfigurieren von Cloud Service Mesh benötigen.
Schließen Sie die Cloud Service Mesh-Installation ab, um das automatische Einfügen des Sidecar-Proxys für Ihre Arbeitslasten zu aktivieren. Details finden Sie unter Zur neuen Steuerungsebene wechseln.
Audit-Logging verwenden
In diesem Abschnitt wird anhand des Bookinfo-Beispiels gezeigt, wie das Audit-Logging angewendet wird.
Stellen Sie die Beispielanwendung Bookinfo im Standard-Namespace bereit.
Rufen Sie die externe IP-Adresse des Ausgangsgateways ab und senden Sie Anfragen an die Beispielanwendung, um Traffic zu generieren.
Öffnen Sie in der Google Cloud Console das Navigationsmenü
und wählen Sie Logging > Log-Explorer aus:Wählen Sie ein Google Cloud-Projekt aus.
Da Sie noch keine Audit-Richtlinie bereitgestellt haben, sind auch noch keine Audit-Logs vorhanden. Beachten Sie, dass sich das Audit-Log vom Zugriffslog unterscheidet. Um Zugriffslogs von
stackdriver
aufzurufen, geben Sie die folgende Abfrage in das Feld Query Builder ein und klicken Sie auf Abfrage ausführen:logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"
Weitere Informationen zur Verwendung des Log-Explorers finden Sie unter Log-Explorer – Übersicht.
Audit-Richtlinie konfigurieren und Audit-Logs prüfen
Dieser Abschnitt erläutert verschiedene Optionen zur Überprüfung der Bookinfo-Anwendung. Nachdem Sie die Audit-Richtlinie bereitgestellt haben, können Sie einige Anfragen senden und dann das Audit-Log im Log-Explorer prüfen.
Geben Sie den folgenden Befehl ein, um Anmeldedaten für die Authentifizierung zur Interaktion mit dem Cluster abzurufen. Mit diesem Befehl wird auch der aktuelle Kontext für
kubectl
auf den Cluster festgelegt.gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_ID \ --zone=CLUSTER_LOCATION
Wenden Sie die folgende Audit-Richtlinie zur Überprüfung von
GET
-Anfragen an den Pfad/productpage
an:kubectl apply -f - << EOF apiVersion: "security.istio.io/v1beta1" kind: "AuthorizationPolicy" metadata: name: "audit-productpage" namespace: default spec: action: AUDIT rules: - to: - operation: methods: ["GET"] paths: ["/productpage"] EOF
Stellen Sie einige Anfragen an „Bookinfo“.
Geben Sie im Log-Explorer die folgende Abfrage in das Feld Query Builder ein und klicken Sie auf Abfrage ausführen:
logName="projects/PROJECT_ID/logs/server-istio-audit-log"
Die Abfrage gibt Logs etwa in folgender Weise zurück:
Wenden Sie die folgende Richtlinie zur Überprüfung von Anfragen an den Dienst
bookinfo-ratings
an. Audit-Richtlinien sind additiv. Nachdem Sie die folgende Richtlinie angewendet haben, werden Audit-Logs für Anfragen sowohl an „ProductPage“ als auch an „Ratings“ angezeigt.kubectl apply -f - << EOF apiVersion: "security.istio.io/v1beta1" kind: "AuthorizationPolicy" metadata: name: "audit-ratings" namespace: default spec: action: AUDIT rules: - from: - source: principals: ["cluster.local/ns/default/sa/bookinfo-ratings"] to: - operation: methods: ["GET"] EOF
Die neue Audit-Richtlinie muss zuerst weitergegeben werden, damit sie in Kraft tritt.
Stellen Sie mindestens 10 Anfragen an „Bookinfo“, damit der Bewertungsdienst erreicht wird. Prüfen Sie dann das Audit-Log im Log-Explorer. Das Audit-Log sieht in etwa so aus:
Wenden Sie die folgende Audit-Richtlinie auf alle Dienste im Standard-Namespace an.
kubectl apply -f - << EOF apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: namespace: default name: "audit-all" spec: action: AUDIT rules: - {} EOF
Stellen Sie weitere Anfragen an „Bookinfo“ und prüfen Sie dann das Audit-Log im Log-Explorer. Das Audit-Log erfasst nun alle Anfragen:
Wenn Sie die Audit-Richtlinie wieder auf „ProductPage“ und „Ratings“ beschränken möchten, können Sie dafür die Richtlinie
audit-all
löschen:kubectl delete authorizationpolicy audit-all -n default
Fehlerbehebung
Wenn nach der Aktivierung einer Audit-Richtlinie keine Audit-Logs angezeigt werden, führen Sie Folgendes aus:
Sorgen Sie dafür, dass für den im Log-Explorer angegebenen Zeitraum Traffic vorhanden ist. Wenn Sie mit „Bookinfo“ testen, können Sie Anfragen durch mehrmaliges Ausführen des folgenden Befehls senden:
curl -s http://EXTERNAL_IP/productpage | grep Bookstore
Prüfen Sie, ob im Ausgangsgateway eine
AuthorizationPolicy
vorhanden ist, die Anfragen an den überprüften Dienst blockiert.Prüfen Sie mit dem folgenden Filter im Log-Explorer die Zugriffslogs von
stackdriver
, um festzustellen, ob Ihre Anfragen die Anwendung erreicht haben:logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"
Um zu gewährleisten, dass Stackdriver konfiguriert und das Audit-Log aktiviert ist, lesen Sie die aktuelle Konfiguration im
istiod
-Status aus. Suchen Sie inconfig_dump
nachenable_audit_log
und nach dem Namen Ihrer Audit-Richtlinie:istioctl dashboard envoy POD_NAME.NAMESPACE
Um zu gewährleisten, dass Ihre Anfragen mit den Audit-Richtlinienregeln übereinstimmen, prüfen Sie die Logs zur Fehlerbehebung für die rollenbasierte Zugriffssteuerung (RBAC). Aktivieren Sie das RBAC-Logging zur Fehlerbehebung mit folgendem Befehl:
kubectl exec POD_NAME -n NAMESPACE -c istio-proxy -- pilot-agent request POST 'logging?rbac=debug'
Stellen Sie einige Anfragen und prüfen Sie dann die Logs für den Pod mit dem Befehl
kubectl logs
:kubectl logs POD_NAME -n NAMESPACE -c istio-proxy