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. Audit-Logs lassen sich im Log-Explorer von Cloud Logging in der Google Cloud Console aufrufen. In dieser Anleitung wird erläutert, wie Sie Anthos Service Mesh der GKE in Google Cloud installieren, damit Sie eine Audit-Richtlinie verwenden können.

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.

Anthos Service Mesh-Installation anpassen

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

  1. Folgen Sie der Anleitung unter Anthos Service Mesh in GKE installieren, um Anthos Service Mesh mit einem von Google bereitgestellten Skript zu installieren. Schließen Sie beim Ausführen des Skripts die folgende Option ein:

    --option audit-authorizationpolicy

    Beispiel:

    ./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --output_dir DIR_PATH  \
  --enable_all \
  --option audit-authorizationpolicy

  2. Schließen Sie die Anthos Service Mesh-Installation ab, um das automatische Einfügen des Sidecar-Proxys für Ihre Arbeitslasten zu aktivieren. Weitere Informationen finden Sie unter Arbeitslasten bereitstellen und bereitstellen.

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:

    Image

  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:

    Image

  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:

    Image

  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

    Image Image Image

  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