Audit-Richtlinien für Ihre Dienste konfigurieren
Mit einer Audit-Richtlinie können Sie den Datenzugriff auf Ihre Dienste in Anthos Service Mesh überprüfen. 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 festlegen, wann ein Audit-Log erstellt wird und was darin enthalten sein soll. In dieser Anleitung wird erläutert, wie Sie Anthos 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
- GKE on VMware
- Google Distributed Cloud Virtual for 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 haben die Audit-Logs von Anthos Service Mesh das gleiche Zuverlässigkeitsattribut wie herkömmliche Zugriffslogs. Wenn beispielsweise ein Arbeitslast-Pod neu gestartet wird, gehen einige Audit-Logs für die Arbeitslast verloren, wenn sie nicht explizit 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
Anthos Service Mesh bietet Ihnen die Möglichkeit, Gateways als Teil Ihres Service Mesh bereitzustellen und zu verwalten. 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.
Standardmäßig installiert asmcli
das istio-ingressgateway
nicht. Wir empfehlen, die Steuerungsebene und die Gateways separat bereitzustellen und zu verwalten.
Weitere Informationen finden Sie unter Gateways installieren und aktualisieren. Wenn Sie das standardmäßige istio-ingressgateway
für die clusterinterne Steuerungsebene installieren möchten, fügen Sie das Argument --option legacy-default-ingressgateway
ein.
Anthos Service Mesh-Installation anpassen
Um eine Audit-Richtlinie zu verwenden, müssen Sie die Installation von Anthos Service Mesh entsprechend ausführen.
Installationen
Folgen Sie der Anleitung unter Anthos 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 Anthos Service Mesh benötigen.
Schließen Sie die Anthos 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
Führen Sie die Schritte unter Anthos Service Mesh aktualisieren aus. 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 Anthos Service Mesh benötigen.
Schließen Sie die Anthos 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