Skip to content
downpipes docs

Forward the downpipes audit trail to Splunk

Splunk receives the downpipes audit trail through its HTTP Event Collector (HEC). The engine dials out to your HEC endpoint on the scheduler tick and posts each audit event as an HEC event object, and the HEC auto-extracts the key-value fields on arrival, so events are searchable straight away with nothing to map by hand.

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 Splunk role that can create an HTTP Event Collector token, such as admin.
  • Network reachability from your engine to the HEC endpoint (port 8088 on Splunk Enterprise, or the collector URL for your Splunk Cloud stack), and owner access to the downpipes console.

Set it up

  1. In Splunk, open Settings, Data inputs, HTTP Event Collector and confirm HEC is enabled (Global Settings, All Tokens: Enabled).
  2. Choose New Token and give it a name. You do not need to set a source type: every event the engine sends carries sourcetype downpipe:audit in its own HEC envelope, which takes precedence over the token’s setting. The default index is fine.
  3. Copy the token value. Note your HEC endpoint URL, which is https://<your-splunk-host>:8088/services/collector on Splunk Enterprise, or the collector URL shown for your Splunk Cloud stack.
  4. Check the certificate on that exact host and port before you go further, because it is the single most common reason this feed never delivers. The Workers runtime verifies the chain against the public trust store and the handshake fails before the request is sent, so your token is never offered. The engine issues a plain fetch and inherits that behaviour rather than implementing it, which is why there is no setting here to relax; it reports the outcome as network-tls. By default splunkd serves port 8088 with its own self-signed certificate (CN=SplunkServerDefaultCert), even where 443 on the same host serves a valid chain. Install a publicly trusted certificate on the HEC listener, or point the push at the dedicated ingest hostname your Splunk Cloud plan publishes (http-inputs-<stack>.splunkcloud.com).
  5. In the downpipes console, open Integrations, choose the Splunk tile, and set up the SIEM audit push there. This is owner-only and asks for a fresh step-up sign-in.
  6. This tile fixes Delivery to HTTP endpoint and Format to Splunk HEC, with no picker to set either. Paste your HEC endpoint URL into Endpoint URL.
  7. Paste the literal string Splunk <token> as the Auth secret: the word Splunk, one space, then your token. HEC treats that Splunk prefix as part of the authentication scheme, not decoration, so the token on its own will not authenticate.
  8. Leave Enabled ticked to drain from the next scheduler tick, or clear it to test before any real event leaves. Choose Configure to save. If your account has a second owner, the save waits for that owner to approve it.
  9. Choose Test send. The engine pushes one synthetic audit-shaped event and reports Splunk’s response. A test send works whether the destination is enabled or not, and never advances the delivery cursor.
  10. If you cleared Enabled at step 8, choose Enable now. From the next scheduler tick, the engine forwards every audit event above the cursor.

What lands in Splunk

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":1751681648,"source":"downpipes","sourcetype":"downpipe:audit","event":{"seq":4097,"action":"restore-approve","outcome":"success","actorEmail":"ops@acme.example","...":"..."}}

The HEC extracts those fields on arrival, so a search like sourcetype=downpipe:audit action=restore-approve works immediately.

Good to know

  • Delivery is at-least-once, not exactly-once. Every event carries a stable seq and a hash; index on either and a re-sent event lands as a duplicate you can drop rather than a second incident. The feed also carries operator identity (member emails, source IPs, roles and approver emails) and no backup data or secret values, so apply your Splunk data-handling rules to it as you would any access log.
  • The same audit events can be pulled rather than pushed instead. For the pull feed and the shared push mechanics, see Forwarding the audit log to your SIEM.

Last updated .