Audit-Log-Ereignisse an Cloud Run weiterleiten

Console

1. Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.

   Zur Projektauswahl

2. Aktivieren Sie die Cloud Logging, Eventarc und Eventarc Publishing APIs.

   Aktivieren Sie die APIs

3. Aktivieren Sie gegebenenfalls die API, die mit den Cloud-Audit-Logs-Ereignissen verknüpft ist. Aktivieren Sie beispielsweise für Cloud Functions-Audit-Logs die Cloud Functions API.

4. Falls noch nicht geschehen, erstellen Sie ein nutzerverwaltetes Dienstkonto und weisen Sie ihm die erforderlichen Rollen und Berechtigungen zu, damit Eventarc Ereignisse für Ihren Zieldienst verwalten kann.

   1. Wechseln Sie in der Google Cloud Console zur Seite Dienstkonto erstellen.

      Zur Seite „Dienstkonto erstellen“

   2. Wählen Sie Ihr Projekt aus.

   3. Geben Sie im Feld Dienstkontoname einen Namen ein. Die Google Cloud Console füllt das Feld Dienstkonto-ID anhand dieses Namens aus.

      Geben Sie im Feld Dienstkontobeschreibung eine Beschreibung ein. Beispiel: Service account for event trigger

   4. Klicken Sie auf Erstellen und fortfahren.

   5. Wählen Sie für einen entsprechenden Zugriff in der Liste Rolle auswählen die erforderlichen IAM-Rollen (Identity and Access Management) aus, die Ihrem Dienstkonto für authentifizierte oder nicht authentifizierte Aufrufe zugewiesen werden sollen. Weitere Informationen finden Sie unter Rollen und Berechtigungen für Cloud Run-Ziele.

      Klicken Sie auf add Weitere Rolle hinzufügen, um weitere Rollen hinzuzufügen.

   6. Klicken Sie auf Weiter.

   7. Klicken Sie zum Abschließen der Erstellung des Dienstkontos auf Fertig.

gcloud

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. Aktivieren Sie die Cloud Logging, Eventarc und Eventarc Publishing APIs.

   gcloud services enable logging.googleapis.com \
     eventarc.googleapis.com \
     eventarcpublishing.googleapis.com
   

3. Aktivieren Sie gegebenenfalls die API, die mit den Cloud-Audit-Logs-Ereignissen verknüpft ist. Aktivieren Sie beispielsweise für Cloud Functions-Audit-Logs cloudfunctions.googleapis.com.

4. Falls noch nicht geschehen, erstellen Sie ein nutzerverwaltetes Dienstkonto und weisen Sie ihm die erforderlichen Rollen und Berechtigungen zu, damit Eventarc Ereignisse für Ihren Zieldienst verwalten kann.

   1. Erstellen Sie das Dienstkonto:

      gcloud iam service-accounts create SERVICE_ACCOUNT_NAME
      

      Ersetzen Sie SERVICE_ACCOUNT_NAME durch den Namen des Dienstkontos. Der Name des Dienstkontos muss zwischen 6 und 30 Zeichen lang sein und darf alphanumerische Zeichen in Kleinschreibung sowie Bindestriche enthalten. Nachdem Sie ein Dienstkonto erstellt haben, können Sie den Namen nicht mehr ändern.

   2. Erteilen Sie die erforderlichen IAM-Rollen oder -Berechtigungen (Identity and Access Management) für authentifizierte oder nicht authentifizierte Aufrufe. Weitere Informationen finden Sie unter Rollen und Berechtigungen für Cloud Run-Ziele.

Console

1. Rufen Sie in der Google Cloud Console die Seite mit den Eventarc-Triggern auf.

   Zur Seite "Trigger"

2. Klicken Sie auf add_boxTrigger erstellen.
3. Geben Sie einen Triggernamen ein.

   Dies ist die ID des Triggers. Sie muss mit einem Buchstaben beginnen. Sie kann bis zu 63 Kleinbuchstaben, Ziffern oder Bindestriche enthalten.

4. Wählen Sie als Triggertyp die Option Google-Quellen aus.
5. Wählen Sie einen Ereignisanbieter aus.

   Dies ist der Google-Dienst, der die Ereignisquelle über die Audit-Logs bildet. Wählen Sie beispielsweise BigQuery aus.

   Beachten Sie, dass der Name des Ereignisanbieters, der in der zugehörigen Google Cloud-Dokumentation verwendet wird, möglicherweise nicht das Präfix Cloud oder Google Cloud hat. In der Console wird Memorystore for Redis beispielsweise als Google Cloud Memorystore for Redis bezeichnet.

6. Wählen Sie in der Liste Ereignistyp aus den Ereignissen über Cloud-Audit-Logs einen Ereignistyp aus.
7. Entscheiden Sie sich für eine der folgenden Möglichkeiten:
   • Beliebige Ressource: Dies ist die Standardeinstellung und enthält dynamisch erstellte Ressourcen, deren Kennungen bei der Erstellung generiert wurden.
   • Bestimmte Ressource: Sie müssen den vollständigen Ressourcennamen angeben.
   • Pfadmuster: Sie können mithilfe eines Pfadmusters nach Ressourcen filtern. Geben Sie beispielsweise projects/_/buckets/eventarc-bucket/objects/random.txt oder projects/_/buckets/**/r*.txt ein.
8. Wählen Sie zur Angabe der Codierung der Ereignisnutzlast in der Liste Inhaltstyp des Ereignisdaten die Option application/json oder application/protobuf aus.

   Beachten Sie, dass eine im JSON-Format formatierte Ereignisnutzlast größer als eine in Protobuf formatierte ist. Dies kann sich auf die Zuverlässigkeit auswirken, je nach Ereignisziel und Limits der Ereignisgröße. Weitere Informationen finden Sie unter Bekannte Probleme.

9. Wählen Sie in der Liste Region eine Region aus.

   Cloud-Audit-Log-Trigger für Eventarc sind in bestimmten Regionen und in der globalen Region verfügbar, jedoch nicht an Standorten mit zwei oder mehreren Regionen. Zur Vermeidung von Leistungs- und Datenstandortproblemen, die durch einen globalen Trigger verursacht werden, sollte der Standort mit dem des Google Cloud-Dienstes übereinstimmen, der Ereignisse generiert. Weitere Informationen finden Sie unter Eventarc-Standorte.

   Wenn Sie den globalen Standort angeben, erhalten Sie Ereignisse von allen Standorten, die Übereinstimmungen für die Ereignisfilter liefern. Durch Erstellen eines globalen Eventarc-Triggers können Sie beispielsweise Ereignisse von Ressourcen in den Mehrfachregionen EU und USA empfangen.

   Beachten Sie, dass es ein bekanntes Problem bei Cloud-Audit-Log-Triggern für Compute Engine gibt, das dazu führt, dass Ereignisse aus einer einzelnen Region stammen: us-central1. Dies gilt unabhängig davon, wo sich die VM-Instanz tatsächlich befindet. Legen Sie den Trigger-Standort entweder auf us-central1 oder auf global fest, wenn Sie den Trigger erstellen.

?
10. Wählen Sie das Dienstkonto aus, das Ihren Dienst oder Workflow aufruft.

    Alternativ können Sie ein neues Dienstkonto erstellen.

    Dies gibt die E-Mail-Adresse des IAM-Dienstkontos (Identity and Access Management) an, die dem Trigger zugeordnet ist und für die Sie zuvor bestimmte Rollen zugewiesen haben, die für Eventarc erforderlich sind.

11. Wählen Sie in der Liste Ereignisziel die Option Cloud Run aus.
12. Wählen Sie einen Dienst aus.
    

    Dies ist der Name des Dienstes, der die Ereignisse für den Trigger empfängt. Der Dienst muss sich im selben Projekt wie der Trigger befinden und empfängt Ereignisse als HTTP-POST-Anfragen, die an seinen Root-URL-Pfad (/) gesendet werden, wenn das Ereignis erzeugt wird.

13. Optional können Sie den Dienst-URL-Pfad angeben, an den die eingehende Anfrage gesendet werden soll.

    Dies ist der relative Pfad im Zieldienst, an den die Ereignisse für den Trigger gesendet werden sollen. Beispiel: /, /route, route, route/subroute.

14. Klicken Sie auf Erstellen.

Nachdem ein Trigger erstellt wurde, können die Ereignisquellenfilter nicht mehr geändert werden. Erstellen Sie stattdessen einen neuen Trigger und löschen Sie den alten. Weitere Informationen finden Sie unter Trigger verwalten.

gcloud

Wenn Sie einen gcloud eventarc triggers create-Befehl zusammen mit den erforderlichen und optionalen Flags ausführen, können Sie einen Trigger erstellen.

gcloud eventarc triggers create TRIGGER \
    --location=LOCATION \
    --destination-run-service=DESTINATION_RUN_SERVICE \
    --destination-run-region=DESTINATION_RUN_REGION \
    --event-filters="type=google.cloud.audit.log.v1.written" \
    --event-filters="serviceName=SERVICE_NAME" \
    --event-filters="methodName=METHOD_NAME" \
    --event-data-content-type="EVENT_DATA_CONTENT_TYPE" \
    --service-account=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

Ersetzen Sie dabei Folgendes:

• TRIGGER: die ID des Triggers oder eine voll qualifizierte Kennzeichnung.
• LOCATION: der Standort des Eventarc-Triggers. Alternativ können Sie das Attribut eventarc/location festlegen. Beispiel: gcloud config set eventarc/location us-central1.

  Cloud-Audit-Log-Trigger für Eventarc sind in bestimmten Regionen und in der globalen Region verfügbar, jedoch nicht an Standorten mit zwei oder mehreren Regionen. Zur Vermeidung von Leistungs- und Datenstandortproblemen, die durch einen globalen Trigger verursacht werden, sollten der Standort mit dem des Google Cloud-Dienstes übereinstimmen, der Ereignisse generiert. Weitere Informationen finden Sie unter Eventarc-Standorte.

  Wenn Sie den globalen Standort angeben, erhalten Sie Ereignisse von allen Standorten, die Übereinstimmungen für die Ereignisfilter liefern. Durch Erstellen eines globalen Eventarc-Triggers können Sie beispielsweise Ereignisse von Ressourcen in den Mehrfachregionen EU und USA empfangen.

  Beachten Sie, dass es ein bekanntes Problem bei Cloud-Audit-Log-Triggern für Compute Engine gibt, das dazu führt, dass Ereignisse aus einer einzelnen Region stammen: us-central1. Dies gilt unabhängig davon, wo sich die VM-Instanz tatsächlich befindet. Legen Sie den Trigger-Standort entweder auf us-central1 oder auf global fest, wenn Sie den Trigger erstellen.

• DESTINATION_RUN_SERVICE: der Name des Cloud Run-Dienstes, der die Ereignisse für den Trigger empfängt. Der Dienst kann sich an einem der von Cloud Run unterstützten Standorte befinden und muss sich nicht am selben Standort wie der Trigger befinden. Er muss sich aber im selben Projekt wie der Trigger befinden. Der Dienst empfängt Ereignisse als HTTP-POST-Anfragen, die an seinen Root-URL-Pfad (/) gesendet werden, wenn das Ereignis erzeugt wird.
• DESTINATION_RUN_REGION: (optional) die Region, in der sich der Cloud Run-Zieldienst befindet. Wenn keine Angabe erfolgt, wird davon ausgegangen, dass sich der Dienst in derselben Region wie der Trigger befindet.

• SERVICE_NAME: die Kennzeichnung des Google Cloud-Dienstes.
• METHOD_NAME: die Kennzeichnung des Vorgangs.

• EVENT_DATA_CONTENT_TYPE: (optional) die Codierung der Ereignisnutzlast. Das kann application/json oder application/protobuf sein. Die Standardcodierung ist application/json.

  Beachten Sie, dass eine im JSON-Format formatierte Ereignisnutzlast größer als eine in Protobuf formatierte ist. Dies kann sich auf die Zuverlässigkeit auswirken, je nach Ereignisziel und Limits der Ereignisgröße. Weitere Informationen finden Sie unter Bekannte Probleme.

• SERVICE_ACCOUNT_NAME: der Name Ihres nutzerverwalteten Dienstkontos.
• PROJECT_ID ist Ihre Google Cloud-Projekt-ID.

Hinweise:

• Diese Flags sind erforderlich:

  • --event-filters="type=google.cloud.audit.log.v1.written"
  • --event-filters="serviceName=VALUE"
  • --event-filters="methodName=VALUE"

• Optional können Sie Ereignisse für eine bestimmte Ressource filtern. Verwenden Sie dazu das Flag --event-filters="resourceName=VALUE" und geben Sie den vollständigen Pfad zur Ressource an. Lassen Sie das Flag für dynamisch erstellte Ressourcen weg, deren Kennzeichnungen zur Erstellungszeit generiert werden. Alternativ können Sie Ereignisse für eine Reihe von Ressourcen filtern, wenn Sie das Flag --event-filters-path-pattern="resourceName=VALUE" verwenden und das Muster für den Ressourcenpfad angeben.

• Jeder Trigger kann mehrere Ereignisfilter haben, die durch Kommata in einem --event-filters=[ATTRIBUTE=VALUE,...]-Flag getrennt sind. Sie können das Flag aber auch wiederholen, um weitere Filter hinzuzufügen. Nur Ereignisse, die mit allen Filtern übereinstimmen, werden an das Ziel gesendet. Platzhalter und reguläre Ausdrücke werden nicht unterstützt.
• Nachdem ein Trigger erstellt wurde, kann der Ereignisfiltertyp nicht mehr geändert werden. Für einen anderen Ereignistyp müssen Sie einen neuen Trigger erstellen.
• Mit dem Flag --service-account wird die E-Mail-Adresse des IAM-Dienstkontos (Identity and Access Management) angegeben, das mit dem Trigger verknüpft ist.
• Optional können Sie einen relativen Pfad im Cloud Run-Zieldienst angeben, an den die Ereignisse für den Trigger durch Verwendung des Flags --destination-run-path gesendet werden sollen.

Beispiel:

  gcloud eventarc triggers create helloworld-trigger \
      --location=us-central1 \
      --destination-run-service=helloworld-events \
      --destination-run-region=us-central1 \
      --event-filters="type=google.cloud.audit.log.v1.written" \
      --event-filters="serviceName=bigquery.googleapis.com" \
      --event-filters="methodName=google.cloud.bigquery.v2.JobService.InsertJob" \
      --service-account=${SERVICE_ACCOUNT_NAME}@${PROJECT_ID}.iam.gserviceaccount.com

Dadurch wird ein Trigger namens helloworld-trigger für Audit-Logs erstellt, die von bigquery.googleapis.com geschrieben werden, und für den Vorgang, der als google.cloud.bigquery.v2.JobService.InsertJob identifiziert wird.

Terraform

Sie können einen Trigger für ein Cloud Run-Ziel mit Terraform erstellen. Weitere Informationen finden Sie unter Trigger mit Terraform erstellen.

Console

1. Rufen Sie in der Google Cloud Console die Seite mit den Eventarc-Triggern auf.

   Zur Seite "Trigger"

   Auf dieser Seite werden Ihre Trigger an allen Standorten aufgelistet. Außerdem enthält sie Details wie Namen, Regionen, Ereignisanbieter, Ziele usw.

2. So filtern Sie die Trigger:

   1. Klicken Sie auf filter_list Filter oder das Feld Trigger filtern.
   2. Wählen Sie in der Liste Attribute eine Option aus, nach der die Trigger gefiltert werden sollen.

   Sie können ein einzelnes Attribut auswählen oder den logischen Operator OR verwenden, um weitere Attribute hinzuzufügen.

3. Klicken Sie zum Sortieren der Trigger neben jeder unterstützten Spaltenüberschrift auf arrow_upward Sortieren.

gcloud

Führen Sie den folgenden Befehl aus, um die Trigger aufzulisten:

gcloud eventarc triggers list --location=-

Dieser Befehl listet Ihre Trigger an allen Standorten auf und enthält Details wie Namen, Typen, Ziele und Status.