Requirements
What the Splunk add-on needs before you install it: a supported Splunk version, the right roles, outbound HTTPS and a Whisper API key.
On this page (6)
Requirements Documentation
The add-on runs on your search heads, sends the indicators you look up to Whisper over HTTPS, and needs a Whisper API key. It creates no index, so there is nothing to provision before you install it.
Splunk platform
| Platform | Version 2.0.0 runs on |
|---|---|
| Splunk Enterprise | 10.2 and 10.4 |
| Splunk Cloud Platform | Victoria Experience and Classic Experience |
| Splunk Enterprise Security | Not required |
The add-on needs Python 3.13, which Splunk Enterprise 10.2 and later select for it automatically. Splunk Enterprise 9.4 and 10.0 do not provide Python 3.13, so the add-on does not run on them.
Where it runs
Install it on the search heads your users search from: a standalone instance, or the search heads of a distributed deployment. Indexers and forwarders need neither the add-on nor network access. A search head cluster is not among the deployments 2.0.0 declares; if you run one, push the add-on from the deployer rather than installing it on each member. Deployment architecture explains what runs where.
Roles and capabilities
| To do this | You need |
|---|---|
| Accept the statement, save the API key, set the proxy and the log level | admin or sc_admin |
Run whisperlookup, whisperenrich, whisperquery and whisperschema, the macros built on them, and the Investigate dashboard | whisper_user, plus list_storage_passwords on a role of your own |
Remove expired cache rows with whisperflush mode=expired | whisper_user |
Empty every collection the add-on ships with whisperflush mode=all | admin or sc_admin |
whisper_user inherits Splunk's user role and adds search access to _internal, where the add-on writes its log. Beyond _internal, it reaches the indexes Splunk's user role reaches.
The commands read the saved API key under the searching account's own session, and Splunk governs that read with its list_storage_passwords capability. The capability is instance-wide: whoever holds it can read every credential stored on that search head, other apps' included. That is why the add-on does not fold it into whisper_user. Grant it on a role of your own, to the accounts that need to run the commands.
Network
| Destination | Protocol and port | From |
|---|---|---|
graph.whisper.security | HTTPS, 443 | Each search head that runs the commands |
The connection is outbound only; the add-on opens no listening port.
- Proxy. An HTTP or SOCKS5 proxy works, set under Configuration › Settings. An HTTPS proxy is set as
http. SOCKS4 is not supported. - TLS inspection. A proxy that decrypts and re-signs TLS breaks the connection, so exempt
graph.whisper.securityfrom inspection. - Splunk Cloud. Outbound HTTPS is allowlisted per destination. An
sc_adminopens port 443 with an Admin Config Service (ACS) outbound-ports request, plus anoutbound-ports-v6request for IPv6, or you configure a proxy.
A Whisper API key
Every command that calls Whisper needs a key, and so do the macros and the Investigate dashboard. Sign up and copy your key from the Whisper console. The add-on keeps it in Splunk's credential store, never in a configuration file, a KV Store row or a log.
What leaves your deployment
The indicator you look up and the add-on's version, with your Whisper API key to authenticate the call. Your event data, field values, user names and search text are never sent. Nothing at all is sent until a Splunk administrator accepts the add-on's statement on the Account tab; Install and configure quotes it in full.