Skip to content
downpipes docs

Forward the downpipes audit trail to Google Security Operations

Google Security Operations (formerly Chronicle) receives the downpipes audit trail through a SIEM Webhook feed. The engine dials out to the feed’s HTTPS endpoint on the scheduler tick and posts the audit events as newline-delimited JSON. SecOps also has an Ingestion API, but it needs an OAuth2 service-account key that a header-based push cannot mint, so the Webhook feed is the right target here.

Two things are specific to SecOps: the Webhook feed authenticates with both an API key and a secret, and SecOps only normalises the fields once you assign the feed a Log type. Until you set the log type, events land as raw JSON rather than parsed fields, so this platform needs that one-time step where Splunk and Datadog do not.

Because the engine makes the outbound call, a Cloudflare Access perimeter on your console hostname never blocks this: there is no inbound request for Access to turn away.

What you need

  • A SecOps role that can create a feed and read the feed’s API key and secret.
  • The Webhook feed’s endpoint, its API key and secret, the Log type to assign, and owner access to the downpipes console.

Set it up

  1. In SecOps, create a feed with source type Webhook. It gives you an endpoint URL and generates an API key and a secret.
  2. Set the feed’s Log type. This is the one-time step SecOps needs: until the feed has a log type, it stores the events but does not normalise them into fields.
  3. In the downpipes console, open Integrations, choose this vendor’s tile, and set up the SIEM audit push there (owner-only, asks for a fresh step-up sign-in).
  4. Set the sink to HTTPS endpoint and the format to NDJSON, and paste the feed endpoint.
  5. Carry the API key and secret the way your feed expects them: as the auth header value (set the header name to match), or as query parameters on the endpoint URL you paste. Confirm the exact names in the SecOps feed configuration.
  6. Choose Test send and confirm SecOps accepts it, then Enable the destination.

What lands in Google SecOps

The engine posts newline-delimited JSON, one raw audit event per line:

{"seq":4097,"ts":"2026-06-19T02:14:08.221Z","actorEmail":"ops@acme.example","action":"restore-approve","outcome":"success","target":{"kind":"restore","runId":"run_01H..."},"...":"..."}

Once the feed has a log type, SecOps normalises these into that log type’s fields. Without one, the same bytes land as unparsed JSON.

Good to know

  • Set the feed’s log type before you rely on searches. SecOps only normalises the audit fields once the Webhook feed has a Log type assigned; until then the events are stored but not parsed.
  • SecOps caps a webhook request at 4 MB. The engine drains up to 500 small audit events per scheduler tick, which stays under that, and a larger backlog drains over successive ticks.
  • If the feed carries its secret as a URL query parameter, that value sits in the endpoint you paste, not in the write-only secret field. Prefer a header credential if your feed offers one, and keep the console’s owner-only access in mind either way.
  • Delivery is at-least-once. Every event carries a stable seq and hash to dedup on. The feed carries operator identity (member emails, source IPs, roles and approver emails); no backup data and no secret values. For the shared push mechanics and the pull alternative, see forwarding the audit log to your SIEM.

Last updated .