Splunk

Connect Splunk to Oleria to see who can do what in your Splunk deployment: which users hold which roles, what each role can do, which indexes each role can search, and who has administrator access. On Splunk Cloud Platform, Oleria also discovers authentication tokens and flags stale or over-privileged ones.

This integration supports Splunk Cloud Platform and self-managed Splunk Enterprise. The two use different Splunk APIs and different credentials. Pick the setup path that matches your deployment below. One Oleria connection maps one Splunk Cloud stack or one Splunk Enterprise instance. Connect additional stacks or instances as separate integrations.

What Oleria discovers

Once connected, Oleria continuously discovers and maps the following:

Users - every Splunk user, with username, full name, email, roles, and lockout status. On Splunk Cloud Platform, Oleria also shows each user’s last successful sign-in.
Roles - built-in roles (admin, power, user, can_delete, and on Splunk Cloud Platform, sc_admin) and custom roles, including the roles each role imports. Each role’s description lists the capabilities it grants.
Indexes - every index, including internal indexes such as _audit and _internal.
Index access - which indexes each role can search. Oleria expands Splunk’s wildcard grants: * becomes every non-internal index, _* becomes every internal index, and a pattern such as prod_* becomes every index it matches.
Role membership - which users hold each role, and which roles inherit from other roles.
Authentication tokens (Splunk Cloud Platform only) - every token on the stack as a non-human identity (NHI), with its owner, audience, expiration, and last use. A token can do whatever its owner’s roles allow, so Oleria shows the owner’s current roles and administrator status on the token.
Activity (optional) - events from Splunk’s _audit index: successful and failed sign-ins, and changes to users, roles, and user preferences. Other audit events appear with their Splunk action name. Requires management API credentials on Splunk Cloud Platform - see Set up Splunk.

Splunk has no user groups, so none appear. Apps, saved searches, dashboards, and other knowledge objects aren’t synced.

Risk signals

Oleria reports these risks for Splunk:

Risk	Severity	When Oleria reports it
Account has administrator-level privileges	High	The user holds the `admin` or `sc_admin` role, or the `admin_all_objects` capability.
Authentication token unused for an extended period (or never used)	Moderate	The token has never been used, or was last used more than 90 days ago. Change the window with Stale Token Days. Splunk Cloud Platform only.
Token privilege is not independently scoped and may exceed its original grant	Moderate	The token’s owner currently holds administrator privileges. Splunk tokens carry no scope of their own, so a token gains every privilege its owner gains after it was issued. Splunk Cloud Platform only.

Prerequisites

Splunk Cloud Platform
Splunk Enterprise

A Splunk Cloud Platform stack with the Admin Config Service (ACS) API available. Splunk doesn’t enable ACS on trial stacks.
A Splunk user with the sc_admin role, and an authentication token for that user. See Set up Splunk.
Optional, for activity: a local Splunk user (with a Splunk password, not a single sign-on user) that can search the _audit index, and Oleria’s IP addresses on your stack’s Search head API access IP allow list. Oleria reads activity from the Splunk management API at https://<stack>.splunkcloud.com:8089, which Splunk Cloud Platform blocks unless the caller’s IP address is allowlisted.

The management port of a Splunk Enterprise search head (default 8089), reachable from Oleria over HTTPS from the internet. Allow inbound connections from Oleria’s IP addresses in your firewall.
A TLS certificate on the management port that is issued by a publicly trusted certificate authority and matches the host name you enter. Oleria verifies the certificate and has no option to skip verification, so Splunk’s default self-signed management certificate doesn’t work.
A local Splunk user (with a Splunk password, not a single sign-on user) for Oleria. See Set up Splunk for the capabilities it needs.

To get Oleria’s IP addresses for your allow list or firewall, contact support@oleria.com.

When you connect, Oleria reads Splunk’s users, roles, and indexes. If the credentials can’t read all three, Oleria refuses the connection and names the one it couldn’t read. Without them, Oleria would show an empty deployment instead of an error.

Set up Splunk

Splunk Cloud Platform
Splunk Enterprise

Choose the Splunk user for Oleria

In Splunk Web, go to Settings -> Users and create a user for Oleria, or choose an existing one. Assign it the sc_admin role.Oleria reads users, roles, indexes, and tokens through the ACS API, and ACS checks the token owner’s capabilities. sc_admin holds every capability Oleria needs by default. Listing indexes through ACS requires indexes_edit and search, and listing tokens requires list_tokens_all or edit_tokens_all, so a read-only role isn’t enough. The user must be able to list tokens. If it can’t, Oleria still connects, but every sync fails until the user can list tokens.

Use a dedicated user rather than a person’s account. A token stops working if its owner loses the sc_admin role or is deleted.

Create an authentication token

Go to Settings -> Tokens. If token authentication is disabled, select Enable Token Authentication.
Select New Token. Set User to the Oleria user, enter an Audience such as Oleria, and set an expiration that matches your credential policy.
Select Create and copy the token. Splunk shows it only once. You enter it as ACS Token when you connect.

When the token expires, syncs stop. Create a new token before then and update the integration in Oleria.

Set up activity (optional)

Skip this step if you don’t need activity. Splunk’s audit trail is available only through the management API on port 8089, and the ACS token can’t sign in there, so Oleria needs a username and password.

Choose a local Splunk user that can search the _audit index. The sc_admin role can. You can use the same user as above if it’s a local user.
Go to Settings -> Server settings -> IP allow list, open the Search head API access tab, and select Add IP subnet for each Oleria IP address. You can also use the ACS API or CLI to add them to the search-api allow list.

You enter this user as Management Username and Management Password when you connect.

Create a role for Oleria (optional)

The simplest setup is to give the Oleria user the built-in admin role. To use a narrower custom role instead, go to Settings -> Roles -> New Role and grant these capabilities:

Capability	Needed for
`list_all_users`	Listing every user. Required.
`list_all_roles`	Listing every role and its capabilities. Required.
`search`	Reading activity from the `_audit` index. On the role’s Indexes tab, also allow searching `_audit`.
`edit_user`	Remediation actions only.

Splunk lets every user list indexes unless you’ve restricted index listing with the indexes_list_all capability. If you have, grant it to this role as well.

Create the Oleria user

Go to Settings -> Users -> New User. Create a local user, such as oleria, set a strong password, and assign the admin role or the role you created.Clear Require password change on user’s first login. Oleria signs in with this password on every request and can’t change it.

Use a dedicated user rather than a person’s account. On Splunk Enterprise, Oleria reads users, roles, indexes, and activity with the same user, so there’s no separate activity setup.

Confirm network access

Confirm Oleria can reach https://<host>:<port> on your search head from the internet, and that the management port presents a publicly trusted certificate for that host name. Oleria uses HTTPS only and doesn’t follow redirects.

Connect Splunk to Oleria

Open the integration

Go to your Oleria workspace, select Integrations -> select Splunk.

Complete the connection form

Select your Connection Mode first. The form updates to show only the fields that mode needs.

Splunk Cloud Platform
Splunk Enterprise

Field	Notes
Connection Mode	Select Cloud (default).
Stack	Required. Your Splunk Cloud stack name, for example `acme`. You can also paste `https://acme.splunkcloud.com` or `https://admin.splunk.com/acme`, and Oleria extracts the stack name.
ACS Token	Required. The token you created.
Management Username	Optional. The local Splunk user for activity. Enter it together with Management Password, or leave both empty to skip activity.
Management Password	Optional. That user’s password.
Stale Token Days	Optional. A whole number of days. Oleria reports tokens unused for longer than this. Defaults to `90`.

Field	Notes
Connection Mode	Select Enterprise.
Host	Required. The host name or IP address of your search head, for example `splunk.example.com`. Don’t include `https://`, a port, or a path - Oleria removes them.
Port	The management port. Defaults to `8089`.
Username	Required. The Oleria user you created.
Password	Required. That user’s password.
Stale Token Days	Optional. Has no effect on Splunk Enterprise, because Oleria doesn’t sync Splunk Enterprise tokens.

Authenticate

Select Authenticate. Oleria checks that the credentials can read users, roles, and indexes, then saves the integration and starts the first sync.Oleria doesn’t check Management Username and Management Password at this step. If they’re wrong, activity fails to sync.

After you save the integration, you can change only ACS Token, Management Password, and Password, for example to rotate a credential. On Splunk Cloud Platform, enter ACS Token every time you update, and if the connection uses management credentials, enter Management Password as well. To change any other field, including adding management credentials to a Cloud connection that has none, remove the integration and connect again.

Verify the integration

Confirm the integration appears on the Connected tab of your Oleria Integrations page, named Splunk (stack) for Splunk Cloud Platform or Splunk (host:port) for Splunk Enterprise. After the first sync completes, review the discovered users, roles, indexes, and index access in your Oleria workspace. If you set up activity, confirm that Splunk activity appears after the first sync. If it doesn’t, check the management username and password and, on Splunk Cloud Platform, the Search head API access IP allow list.

Remediation actions

Oleria runs these actions with the integration’s credentials: the ACS token on Splunk Cloud Platform, or the username and password on Splunk Enterprise. Before each action, Oleria checks that the credential’s Splunk user can administer users. On Splunk Enterprise, it checks for the edit_user capability directly. On Splunk Cloud Platform, it checks the token owner’s edit_user capability when it can identify the owner, and otherwise checks that the token can read the user list.

Action	What it does	Revert
Create user	Creates a local Splunk user with the requested roles, or the `user` role if none are requested. Splunk has no invitation flow, so Oleria sets a random temporary password and requires a password change at first sign-in. Oleria doesn’t show this password to anyone, so set a new password for the user in Splunk before they sign in.	Supported - deletes the user.
Disable user / Delete user	Deletes the user. Splunk has no way to disable a user, so both actions delete. Oleria records the user’s roles, email, and full name first.	Supported - recreates the user with the same username, roles, email, and full name, and a new temporary password that must be changed at first sign-in. If Oleria couldn’t read the user’s roles before deleting, the user comes back with only the `user` role.
Add user to role	Adds the role to the user. If the user already holds it, nothing changes.	Supported - restores the role list the user had before the action.
Remove user from role	Removes the role from the user. If the user doesn’t hold it, nothing changes.	Supported - restores the role list the user had before the action.

Splunk replaces a user’s whole role list on every change. Reverting a role action restores the exact list from before the action, which also undoes any other role changes made to that user since.
Oleria refuses to delete Splunk’s built-in admin user.
Oleria refuses to remove a user’s last role, because Splunk requires every user to hold at least one. Add a replacement role first, or delete the user instead.
Deleting a user who signs in through SAML or LDAP doesn’t stop them from signing in. Splunk recreates the user at their next sign-in unless you also remove them in your identity provider or directory.

Known limitations

Users can’t be disabled. Splunk has no disabled state, so deprovisioning deletes the user. See Remediation actions.
Token listing is required on Splunk Cloud Platform. If the ACS token’s user can’t list tokens, every sync fails, even though the integration connects. Grant list_tokens_all or edit_tokens_all, or use an sc_admin user.
No tokens on Splunk Enterprise. Oleria syncs authentication tokens only from Splunk Cloud Platform. Splunk Enterprise connections show no tokens and no token risks, even if tokens exist.
No last sign-in on Splunk Enterprise. The Splunk Enterprise API doesn’t return users’ last sign-in time.
Administrator detection on Splunk Enterprise. The Splunk Enterprise user list doesn’t include each user’s capabilities, so Oleria flags a user as an administrator only when they hold the admin role directly.
Search filters aren’t reflected. A role’s search filter can limit which events its members see within an index. Oleria shows access to the whole index, so access for roles with a search filter is overstated.
No group mappings. Oleria doesn’t read the LDAP or SAML group-to-role mappings configured in Splunk. Users who sign in through those mappings appear with the roles Splunk has recorded for them.
Service accounts aren’t distinguished. Splunk has no field that marks a user as a service account, so every Splunk user appears as a user account.
MFA and SSO aren’t shown. Splunk doesn’t expose per-user multi-factor authentication or single sign-on settings. Your identity provider enforces them.
Distributed deployments. Oleria lists the indexes defined on the Splunk Enterprise host you connect to. Connect a search head that has your index definitions.
Splunk Cloud Platform domains. Oleria connects to stacks at admin.splunk.com and <stack>.splunkcloud.com. Stacks on other Splunk Cloud domains aren’t supported.
Activity includes Oleria. Oleria’s own requests and searches can appear in Splunk’s audit trail, so they can also appear as activity for the Oleria user.

Contact us

For questions about this integration, contact us at support@oleria.com.

Overview

Generic connectors

Identity providers

HR systems

Cloud infrastructure

Applications

Ticketing

Messaging

What Oleria discovers

Risk signals

Prerequisites

Set up Splunk

Connect Splunk to Oleria

Verify the integration

Remediation actions

Known limitations

Contact us

​What Oleria discovers

​Risk signals

​Prerequisites

​Set up Splunk

​Connect Splunk to Oleria

​Verify the integration

​Remediation actions

​Known limitations

​Contact us

What Oleria discovers

Risk signals

Prerequisites

Set up Splunk

Connect Splunk to Oleria

Verify the integration

Remediation actions

Known limitations

Contact us