Release identity
SHA-256 of the pack file bytes: 616d72b69bac9fe8e852efbba2e7437654b335715040be0db7b67e159c6a97ad
Not in the distributable release manifest. The binary carries a digest-bound manifest of the distributable library; a pack whose bytes differ from its manifest entry — endpoint, tier, allowlist, or credential edited, with provider, version, and review block preserved — fails the digest check, loses distributability, and renders MODIFIED rather than as the shipped reviewed artifact. Review state and artifact status are different facts: the first is a documentation-review declaration, the second is the identity of the exact bytes.
Capabilities (4)
splunk.saved_searches.read v1.0.0R0
- Action
- read
- Endpoint
GET https://splunk-instance.invalid:8089/services/saved/searches- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-splunk-auth-token- Data class
- internal
List saved search configurations: names, schedules and the SPL text itself, which reveals detection logic and internal data layout. The registered path covers the collection read only — single saved-search reads, creation, modification, deletion and dispatch are not registered by this pack.
splunk.indexes.read v1.0.0R0
- Action
- read
- Endpoint
GET https://splunk-instance.invalid:8089/services/data/indexes- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-splunk-auth-token- Data class
- internal
List data indexes: names, storage paths, sizes, event counts and retention settings, which reveal what the deployment collects and keeps. The registered path covers the collection read only — single-index reads and index creation or modification (POST data/indexes) are not registered by this pack.
splunk.search.jobs.read v1.0.0R0
- Action
- read
- Endpoint
GET https://splunk-instance.invalid:8089/services/search/jobs- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-splunk-auth-token- Data class
- internal
List current search jobs: owners, dispatch state, disk usage and the query text of each job, which reveals who searches for what. The registered path covers the collection read only — single-job reads (GET /services/search/jobs/{search_id}), job results and job control are not registered by this pack.
splunk.search.jobs.create v1.0.0R2
- Actions
- create, execute
- Endpoint
POST https://splunk-instance.invalid:8089/services/search/jobs- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-splunk-auth-token- Data class
- pii
Create and dispatch an ad-hoc search job: POST /services/search/jobs makes splunkd create a job that executes the caller-supplied SPL in the search parameter, so the declared AAES actions are create and execute at the R2 floor — this is not a retrieval-only POST. Reading the job's results (GET /services/search/jobs/{search_id}/results) is a separate operation this pack does not register. The SPL is caller-controlled, so this pack cannot pin what data the job touches: that constraint lives honestly in the Splunk role behind the token plus deployment policy, and enabling this capability without a role demonstrated to lack the destructive, writing and notifying capabilities (delete_by_keyword, output_file, run_collect, run_mcollect, run_sendalert, run_custom_command, schedule_search and the edit_* capabilities) is a misconfiguration the pack cannot prevent. Declared data class pii is the conservative default because search results are whatever the SPL selects from the indexes the role may search, and indexed event data routinely contains personal data (IP addresses, usernames, email text); lower it only if the deployment's indexes demonstrably hold none, raise it if they hold regulated data.
Credential reference
The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.
- Reference
secret-ref-splunk-auth-token- Custody
- customer_vault
- Injection
- header (Authorization)
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.
Resources
splunk-deployment(api, internal):https://splunk-instance.invalid:8089/servicessplunk-indexed-data(api, pii):https://splunk-instance.invalid:8089/services/search/jobs
Pack notes and exclusions
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 R2 floor, 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 lives honestly in 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 — a documented exclusion, not an approximated capability.
Review record
Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)
- https://docs.splunk.com/Documentation/Splunk/latest/RESTREF/RESTsearch (retrieved 2026-09-21)
- https://help.splunk.com/en/splunk-enterprise/rest-api-reference/9.4/introspection-endpoints/introspection-endpoint-descriptions (retrieved 2026-09-21)
- https://help.splunk.com/en/splunk-enterprise/leverage-rest-apis/rest-api-reference/9.4/introduction/endpoints-reference-list (retrieved 2026-09-21)
- https://docs.splunk.com/Documentation/Splunk/latest/Security/UseAuthTokens (retrieved 2026-09-21)
- https://docs.splunk.com/Documentation/Splunk/latest/Security/Rolesandcapabilities (retrieved 2026-09-21)
A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.
