Splunk package v1.0.0

A Splunk platform authentication token (JWT) for the customer's own instance, held in the client's own secret manager. The stored material must be the complete Authorization header value: the scheme 'Bearer', one separating space, then the token — 'Bearer <token>' (Splunk also accepts the 'Splunk' scheme; this pack standardizes on the documented Bearer form). The token authenticates with the full role and capabilities of the Splunk user it was issued to: issue it to a dedicated least-privilege service role whose index restrictions and capabilities cover exactly these reads and, where enabled, ad-hoc search without the destructive, writing or notifying capabilities enumerated in the pack notes (delete_by_keyword, output_file, run_collect, run_mcollect, run_sendalert, run_custom_command, schedule_search).

Tokens carry a not-before and an expiry chosen at creation, and Splunk's documentation states expired tokens are unusable — choose a real expiry and rotate; renewal ownership sits with an external deployment process, and the executor injects the stored value verbatim and performs no token lifecycle of its own. Revocation is real but manual: an administrator disabling or deleting the token ends its access, as does disabling token authentication on the instance — do not assume that restricting new token issuance invalidates tokens already issued.

The full token is shown to the requester once at assignment, so capture it into the vault at creation time.

Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

The endpoint authority 'splunk-instance.invalid:8089' is a reserved non-production placeholder (an RFC 2606 reserved TLD) for the customer's splunkd management endpoint: substitute the real management host and port — Splunk Enterprise defaults to port 8089, Splunk Cloud uses https://<deployment-name>.splunkcloud.com:8089 — in the endpoints, the resource locators and the egress allowlist before enabling; the allowlist matches exactly, so all three must be substituted together, substitution is a required deployment step, and allowlisting the reserved host does not make an unsubstituted pack safe (the reserved name is a deliberate fail-closed default: it resolves nowhere by design, so an unsubstituted pack cannot call anything until the installer binds the real host).

Every read endpoint here is a COLLECTION read only: single-record reads (GET /services/saved/searches/{name}, GET /services/data/indexes/{name}, GET /services/search/jobs/{search_id}) are not registered. The ad-hoc search capability creates and dispatches a search job that executes the caller-supplied SPL — registered as create and execute at the minimum R2 tier, not as retrieval-only POST. The SPL in the request's search parameter is caller-controlled, so this pack cannot pin what data the job touches or what the SPL does, and the constraint is enforced by the Splunk role behind the token plus deployment policy — exactly like the role's GRANTs and the adapter's allowlist in the postgres pack.

Splunk documents capabilities as additive and command-gated, so a demonstrably constrained role must omit at least: delete_by_keyword (the delete operator), output_file (outputcsv and outputlookup writes to files and lookups), run_collect and run_mcollect (writes to summary and metrics indexes), run_sendalert (alert notification actions), run_custom_command (custom search commands, which can carry their own effects), schedule_search, rtsearch and schedule_rtsearch, and every edit_* capability; the role's index access restrictions bound what data the SPL can read.

Register it only against a role demonstrated to lack those capabilities; if that boundary cannot be demonstrated, remove the capability — one capability id on an unrestricted endpoint is one permission, and a second id would not create a second one.

Documented exclusions — this pack does not register: saved search creation, modification, deletion or dispatch (POST/DELETE on saved/searches, which can schedule alerting), index creation or modification (POST data/indexes), search job control (DELETE or control actions on search/jobs), knowledge object writes, HEC event ingest (a separate input, default port 8088, that no capability here may reach), servicesNS user-namespace endpoints, and every other splunkd endpoint.