Splunk (Cisco)
F Splunk Cloud Platform
The REST API and ACS admin API take static JWT authentication tokens owned by a Splunk user, and data comes in on static HEC tokens; no OIDC or workload identity path exists. Tokens can be API-rotated and show last use, but inherit their owner's access, may last forever and are not GitHub partner-revoked. Data Manager reaches AWS by role with external ID; Azure, GCP and the add-ons want client secrets or keys.
Docs: docs.splunk.com · Checked 2026-10-22 · source YAML · dispute via PR
Inbound F
How a workload running anywhere authenticates to this product.
Static authentication token (a Splunk-signed JWT bound to one Splunk user, sent as Authorization: Bearer) for the REST API on port 8089 and for the Admin Config Service (ACS) API, plus a static 32-character HEC token for ingesting data. Six-hour ephemeral tokens exist but are minted with a username and password or an existing token.
- docs.splunk.com checked 2026-10-22
“Static authentication tokens let you access a Splunk platform instance. You can create, modify, update and delete them in Splunk Web, and they can last indefinitely.”
- docs.splunk.com checked 2026-10-22
“After you receive a valid token for the instance you want to use, you can use the token to make calls to REST endpoints on the instance. Your access is the same as what you have if you logged in with credentials.”
- docs.splunk.com checked 2026-10-22
“The ACS API uses authentication tokens, in the form of a JSON Web Token (JWT), to authenticate and authorize ACS endpoint requests.”
- admin.splunk.com checked 2026-10-22
“"bearerAuth":{"bearerFormat":"JWT","scheme":"bearer","type":"http"}”
- docs.splunk.com checked 2026-10-22
“You must provide a valid username and password for basic authentication.”
- docs.splunk.com checked 2026-10-22
“The ACS tokens endpoint supports an optional type request parameter, which lets you create an ephemeral JWT token that expires by default after 6 hours.”
- docs.splunk.com checked 2026-10-22
“Each token has a unique value, which is a 128-bit number that is represented as a 32-character globally unique identifier (GUID).”
- docs.splunk.com checked 2026-10-22
“The HTTP Event Collector (HEC) lets you send data and application events to your Splunk deployment over HTTP protocol using token-based authentication.”
Graded on the weakest path a workload must use: the REST API and ACS take static or ephemeral Splunk JWTs, and HEC ingestion takes only a static GUID token with no expiry or rotation (the value cannot be changed, only replaced). The ACS OpenAPI spec declares only basicAuth and a Splunk-issued bearer JWT. Ephemeral tokens (max six hours, created via REST or ACS) would look like grade C for the REST/ACS plane, but they are minted with a Splunk username and password or with another token, so a long-lived root remains, and they do not cover HEC. No OIDC, GitHub Actions, cloud workload identity or token exchange from an external issuer is documented; the SAML and Okta/Azure IdP support is for human login, and tokens are only issued by the Splunk instance itself. Tokens are per search head and are not replicated across the search tier. Splunk Enterprise (self-managed) shares the same token model and is not graded separately; Splunk Observability Cloud (separate access tokens) is a different product.
Outbound B
How this product reaches into your cloud, repos, or other SaaS.
Data Manager onboards AWS by having you create a SplunkDMReadOnly role (plus CloudFormation roles for Firehose) whose trust policy names Splunk's role with an sts:ExternalId; Azure onboarding wants an Entra app client secret, the Data Manager S3 input wants an IAM user's access key, and the Splunk Add-ons for AWS, Google Cloud and Microsoft Cloud Services on Splunk Cloud want an access key, service-account JSON key, or client secret or certificate.
- help.splunk.com checked 2026-10-22
“A SplunkDMReadOnly role allows Splunk Cloud to read metadata from your AWS events and logs.”
- help.splunk.com checked 2026-10-22
“"sts:ExternalId": "<EXTERNAL_ID>"”
- help.splunk.com checked 2026-10-22
“Splunk provides CloudFormation templates to establish the stack set execution role and the Data Manager read role.”
- help.splunk.com checked 2026-10-22
“The access key ID and secret access key for the IAM user.”
- help.splunk.com checked 2026-10-22
“Configure the Data sources, Tenant ID, Client ID, Client Secret, Event Hub subscription ID, Event Hub region, and Data Destination.”
- help.splunk.com checked 2026-10-22
“Ask your GCP admin to create a service account for Data Manager to use to query the status of your deployment.”
- splunk.github.io checked 2026-10-22
“Enter the Key ID and Secret Key credentials for the AWS account that the Splunk platform uses to access your AWS data.”
- splunk.github.io checked 2026-10-22
“Splunk Cloud restricts the use of the Auto-discovered EC2 IAM role feature due to security reasons.”
- splunk.github.io checked 2026-10-22
“The Splunk Add-on for AWS supports the AWS Security Token Service (AWS STS) AssumeRole API action that lets you use IAM roles to delegate permissions to IAM users to access AWS resources.”
- splunk.github.io checked 2026-10-22
“For non-Dedicated accounts, the add-on supports external-account credentials only on AWS and Azure virtual machines.”
- splunk.github.io checked 2026-10-22
“The add-on supports Google Cloud's Application Default Credentials (ADC) feature for customer-managed on-premise instances. This feature isn't supported for cloud instances.”
- splunk.github.io checked 2026-10-22
“Select client_secret for client secret authentication or client_certificate for certificate-based authentication. Default: client_secret”
Checked: Data Manager for AWS (single account, multiple accounts, organizational units: keyless, a customer-created role trusting Splunk's role with an external ID; data is pushed to HEC by Firehose), Data Manager's AWS S3/SQS input (static IAM user access key), Data Manager for Azure (Entra app registration client secret; Event Hubs push), Data Manager for GCP (Terraform you run in your project pushes via Dataflow to HEC; the service account Data Manager uses "to query the status" is configured in-product, and whether a key is handed to Splunk is not publicly verifiable), Splunk Add-on for AWS (on Splunk Cloud the EC2 instance-role path is blocked, so pull inputs need an IAM user access key, optionally chained to AssumeRole), Splunk Add-on for Google Cloud Platform (service-account JSON key; the external-account WIF option needs an AWS or Azure VM you control, and ADC is self-managed only, so neither is documented for Splunk Cloud), Splunk Add-on for Microsoft Cloud Services (client secret by default, or an uploaded certificate private key). The AWS add-on and both Microsoft paths do document least-privilege policies. B because AWS has one keyless path; Azure and GCP have none. Push-based inputs (Firehose, EventBridge, Event Hubs exports) make your cloud hold a Splunk HEC token instead, which is an inbound credential. Federated Search and Edge/Ingest Processor destinations were not assessed.
Hygiene for any static credential the product still issues
| ✗ Expiry enforceable | Fails: ACS and the token docs apply a 30-day default when no expiry is given, but a static token may be set to never expire, and Splunk Cloud customers cannot even change the global default (that authorize.conf setting is Splunk Enterprise only); no maximum lifetime or policy to forbid non-expiring tokens is documented. A changeable default is not an enforced expiry (same call as elastic-cloud-api). HEC tokens have no expiry at all.
|
| ✓ Rotation via API | Authentication tokens can be created, listed, disabled and deleted via the instance REST endpoint services/authorization/tokens and via ACS (/adminconfig/v2/tokens); HEC tokens via ACS (/adminconfig/v2/inputs/http-event-collectors) and the scp Terraform provider. ACS token creation itself requires basic auth with a username and password.
|
| ✗ Scoped keys | Fails. A token carries exactly its owner's access and cannot be narrowed itself, and Splunk documents no service-account or API-only account type. The workaround (create a native local user for the workload, give it a custom role with only the needed capabilities and indexes, and issue the token to it) does not count under the wif.tax rule that scoping passes only when the vendor documents a non-human account type (tenable-vulnerability-management passes on its documented API-only user; rapid7-insight-platform fails on the same workaround). Tokens issued to a human's SAML account inherit all of that person's access. HEC tokens are ingest-only and limited to their allowed indexes, but they are not the API path.
|
| ✓ Last-used visible | Authentication tokens show last-used time and IP in Splunk Web and in the ACS TokenInfo schema (lastUsed, lastUsedIP). No last-used field is documented for HEC tokens.
|
| ✗ Leak revocation | Splunk does not appear in GitHub's supported secret-scanning patterns table at all (no partner, user-alert or push-protection pattern for authentication tokens or HEC tokens), so a leaked token is not reported to Splunk for revocation.
|
Notes
Hygiene is graded on the static authentication tokens used for the REST and ACS APIs: two of five pass (rotation API, last used), so inbound is F. A documented service-account type with its own role would add the scoping pass and lift inbound to D. HEC tokens, which every ingesting workload must hold, are weaker (no expiry, no last-used, no partner revocation; only API management and index scoping pass, two of five) and would be F on their own. An org policy capping token lifetime would also add a pass; inbound moves to B or A only if the REST, ACS and HEC endpoints accept a federated token (GitHub Actions OIDC, cloud workload identity, or a bring-your-own issuer). Outbound moves to A if Data Manager and the add-ons offer keyless Azure (federated credential or multi-tenant app consent) and GCP (service account impersonation) and the AWS add-on accepts a cross-account role on Splunk Cloud without an IAM user key.
Badge
[](https://wif.tax/p/splunk-cloud-platform/)