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

Führen Sie die Schritte unter Abhängige Tools installieren und Cluster validieren aus, um Folgendes zu tun:

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

Passen Sie die Cloud Service Mesh-Installation an, um eine Audit-Richtlinie zu verwenden:

Installationen

  1. Befolgen Sie die Schritte in Installieren Sie das Cloud Service Mesh. 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 Cloud Service Mesh konfigurieren.

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

  1. 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 Cloud Service Mesh konfigurieren.

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

  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ü 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:

    Bild

  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:

    Bild

  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:

    Bild

  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"

    Bild

  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

    Bild Image Bild

  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