Audit-Richtlinien für Ihre Dienste konfigurieren

Mit einer Audit-Richtlinie können Sie den Datenzugriff auf Ihre Dienste in Cloud 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 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
• Google Distributed Cloud

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 Cloud 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.

Hinweis

• Erforderliche Tools installieren
• asmcli herunterladen
• Clusteradministratorberechtigungen erteilen
• Projekt und Cluster validieren

Gateway-Konfiguration vorbereiten

Cloud 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.

asmcli installiert 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.

Anthos Service Mesh-Installation anpassen

Um eine Audit-Richtlinie zu verwenden, müssen Sie die Installation von Cloud Service Mesh entsprechend ausführen.

Audit-Logging verwenden

In diesem Abschnitt wird anhand des Bookinfo-Beispiels gezeigt, wie das Audit-Logging angewendet wird.

1. Stellen Sie die Beispielanwendung Bookinfo im Standard-Namespace bereit.

2. Rufen Sie die externe IP-Adresse des Ausgangsgateways ab und senden Sie Anfragen an die Beispielanwendung, um Traffic zu generieren.

3. Öffnen Sie in der Google Cloud Console das Navigationsmenü menu und wählen Sie Logging > Log-Explorer aus:
   

   Zu „Log-Explorer“

4. Wählen Sie ein Google Cloud-Projekt aus.

5. 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.

1. 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
   

2. 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
   

3. Stellen Sie einige Anfragen an „Bookinfo“.

4. 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:

   

5. 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.

6. 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:

   

7. 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
   

8. Stellen Sie weitere Anfragen an „Bookinfo“ und prüfen Sie dann das Audit-Log im Log-Explorer. Das Audit-Log erfasst nun alle Anfragen:

   

9. 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:

1. 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
   

2. Prüfen Sie, ob im Ausgangsgateway eine AuthorizationPolicy vorhanden ist, die Anfragen an den überprüften Dienst blockiert.

3. 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"
   

   

4. Um zu gewährleisten, dass Stackdriver konfiguriert und das Audit-Log aktiviert ist, lesen Sie die aktuelle Konfiguration im istiod-Status aus. Suchen Sie in config_dump nach enable_audit_log und nach dem Namen Ihrer Audit-Richtlinie:

   istioctl dashboard envoy POD_NAME.NAMESPACE
   

   

5. 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'
   

6. 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
   

Nächste Schritte

• Informationen zur Sicherheit in Cloud Service Mesh