Skip to content
downpipes docs

Send the downpipes audit trail to Cribl

Cribl takes the downpipes audit trail in either direction, so you pick the one that suits your pipeline. For a push, you create a Cribl HEC Source and point the console push at it. For a pull, a Cribl REST Collector polls the audit feed instead. Whichever you pick, Cribl then routes and reshapes each event for whatever sits downstream, which makes it a tidy way to fan the audit trail out to more than one destination.

This page leads with the push path, which is the simpler default: the engine dials out to the Cribl HEC Source on the scheduler tick, so a Cloudflare Access perimeter on your console hostname never blocks it, and there is no exemption to add.

What you need

  • A Cribl Stream or Edge instance where you can add a Source, and a Splunk HEC Source with a token for the push path.
  • Owner access to the downpipes console, and network reachability from your engine to the Cribl HEC URL.

Set it up

  1. In Cribl, create a Source of type Splunk HEC. Note the URL it exposes and a HEC token it will accept.
  2. In the downpipes console, open Integrations, and set up the SIEM audit push. Note where: the Cribl tile opens the pull credential, not the push config, because pulling is the direction Cribl is catalogued for. The audit push is a single destination for the estate and is edited from any push tile, so use Custom endpoint, or the Splunk tile, since a Cribl HEC Source speaks Splunk HEC. Either is owner-only and asks for a fresh step-up sign-in.
  3. Set Delivery to HTTP endpoint, Format to Splunk HEC, and paste the Cribl HEC URL into Endpoint URL.
  4. For the auth secret, paste Splunk <token>: the literal word Splunk, one space, then your token. The HEC Source treats that Splunk prefix as part of the scheme, so the bare token does not authenticate.
  5. Choose Test send. The engine posts one synthetic audit-shaped event and reports Cribl’s response. A test send never advances the delivery cursor. With it accepted, choose Enable, and from the next tick the engine forwards every audit event above the cursor.

Because the push is one destination and the tiles decide which of them displays it by matching format and delivery, a Splunk HEC push to Cribl will appear under the Splunk tile rather than under Cribl’s. Nothing is misrouted, the events go to the Cribl Source you pointed them at, and only the tile the console shows the configuration under differs. Custom endpoint explains that ownership rule in full.

To pull instead, which is the direction the Cribl tile does cover, add a Cribl REST Collector (or a Collector job) that polls https://<your-console-host>/support/audit-feed with an audit-feed credential as a Bearer token, paging by afterSeq. The mint, the Cloudflare Access exemption and the continuity checks are on Wiring the audit feed into your SIEM.

What lands in Cribl

On the push path each event arrives as an HEC event object, with time as epoch seconds, source set to downpipes, sourcetype set to downpipe:audit, and the audit event under event:

{"time":1750299248,"source":"downpipes","sourcetype":"downpipe:audit","event":{"seq":4097,"action":"restore-approve","outcome":"success","actorEmail":"ops@acme.example","...":"..."}}

Cribl parses the HEC object on arrival, so you can route, redact further or reshape from those fields before anything downstream sees them.

Good to know

  • Delivery is at-least-once, not exactly-once. Every event carries a stable seq and a hash; index or dedup on either and a re-sent event lands as a duplicate you can drop rather than a second incident. The feed carries operator identity (member emails, source IPs, roles and approver emails) and no backup data or secret values, so apply your Cribl data-handling rules to it as you would any access log.
  • The push needs no Access exemption; the pull needs one when Access fronts your hostname. For both the push mechanics and the pull feed, see Forwarding the audit log to your SIEM.

Last updated .