> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oleria.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Splunk

> Connect Splunk Cloud Platform or self-managed Splunk Enterprise to Oleria to discover users, roles, index access, authentication tokens, and audit activity, and manage users and role membership.

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.

<Note>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.</Note>

## 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](#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

<Tabs>
  <Tab title="Splunk Cloud Platform">
    * 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](#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.
  </Tab>

  <Tab title="Splunk Enterprise">
    * 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](#set-up-splunk) for the capabilities it needs.
  </Tab>
</Tabs>

<Note>To get Oleria's IP addresses for your allow list or firewall, contact [support@oleria.com](mailto:support@oleria.com).</Note>

<Note>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.</Note>

## Set up Splunk

<Tabs>
  <Tab title="Splunk Cloud Platform">
    <Steps>
      <Step title="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.

        <Note>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.</Note>
      </Step>

      <Step title="Create an authentication token">
        1. Go to **Settings** -> **Tokens**. If token authentication is disabled, select **Enable Token Authentication**.

        2. Select **New Token**. Set **User** to the Oleria user, enter an **Audience** such as `Oleria`, and set an expiration that matches your credential policy.

        3. Select **Create** and copy the token. Splunk shows it only once. You enter it as **ACS Token** when you connect.

        <Note>When the token expires, syncs stop. Create a new token before then and update the integration in Oleria.</Note>
      </Step>

      <Step title="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.

        1. 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.

        2. 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.
      </Step>
    </Steps>
  </Tab>

  <Tab title="Splunk Enterprise">
    <Steps>
      <Step title="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.
      </Step>

      <Step title="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.

        <Note>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.</Note>
      </Step>

      <Step title="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.
      </Step>
    </Steps>
  </Tab>
</Tabs>

## Connect Splunk to Oleria

<Steps>
  <Step title="Open the integration">
    Go to your Oleria workspace, select **Integrations** -> select **Splunk**.
  </Step>

  <Step title="Complete the connection form">
    Select your **Connection Mode** first. The form updates to show only the fields that mode needs.

    <Tabs>
      <Tab title="Splunk Cloud Platform">
        | 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`. |
      </Tab>

      <Tab title="Splunk Enterprise">
        | 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. |
      </Tab>
    </Tabs>
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Note>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.</Note>

## 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. |

<Note>
  * 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.
</Note>

## Known limitations

* **Users can't be disabled.** Splunk has no disabled state, so deprovisioning deletes the user. See [Remediation actions](#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](mailto:support@oleria.com).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.