Create and manage roles with Splunk Web

You can assign roles to users that determine the level of access that those users have to the Splunk platform and the tasks that they can perform. The platform comes with a set of default roles, and you can also create custom roles that you can tailor to the needs of your organization.

Roles can contain one or more capabilities that provide access to specific parts of the Splunk platform. A user that has a role assigned to them receives all of the capabilities that are associated with the role. Roles can inherit capabilities from other roles.

You can access the "Roles" page on a Splunk platform instance by clicking Settings > Roles from the system bar.

The "Roles" control panel

The "Roles" control panel displays a list of all roles that are on the Splunk platform instance. By default, the page lists the roles ascending by name. The page displays the following information in columns, from left to right:

• Name: The role name. You can click on the name to edit that role.
• Actions: This column is a drop-down menu of actions that you can perform on the role. See "Perform actions on roles" in this topic.
• Native Capabilities: The number of Splunk capabilities that the role holds directly. A user that holds this role can perform all of the capabilities that are associated with the role.
• Inherited Capabilities: The number of Splunk capabilities that the role has inherited from one or more other roles. If a role inherits capabilities from other roles, then a user that holds that role can perform all of the capabilities that come with the other roles.
• Default app: The default Splunk application context that a user that holds this role is in when they log in.

Sort the role list

You can click any of the column headers to sort the role list by that column header, with the exception of "Actions". Clicking a column header multiple times toggles whether the role list sorts in ascending or descending order.

Perform actions on roles

You can perform several different actions on an existing user, including but not limited to making edits, cloning, and viewing a list of capabilities that a role has. These actions are available under the Actions column for each role, and you can access them by clicking the Edit link in that column.

• To edit a role, click Edit. The "Edit Role" page appears. See "Add or edit a user" in this topic for further instructions on making changes to the role.
• To view all of the capabilities that a role has, click View Capabilities. This loads the "View Capabilities" page which lists all of the capabilities that the role has.
• To clone a role, click Clone. This action takes you through the "Add or edit a role" process to create a role that is identical to the role you selected.
• To delete a role, click Delete. The instance confirms whether or not you want to delete the role. This option is not available for the admin role.

Manage role inheritance, searched indexes, restrictions, and available search resources

When you add and edit roles, you can modify the following role properties:

• You can manage role inheritance. See "Specify role inheritance" in this topic.
• You can manage the indexes that a role has available to it as well as which indexes the Splunk platform searches by default. See "Specify searchable indexes for a role" in this topic.
• You can apply a search filter to further limit search results. You can either specify the filter manually or use the search filter generator - a wizard that lets you build and populate the filter by using indexed fields and values found in those indexes. See "Specify search restrictions for a role" in this topic.
• You can control resource usage on the platform by limiting disk space usage for search artifacts, the number of searches that the role as a whole can run, and the number of searches that users who hold the role can run individually. See "Specify default app and search limits for a role" in this topic.

While you can have any role inherit from any other role, custom roles that inherit from the admin or power users roles do not automatically inherit administrator-level access to the instance.

• For more information about roles and how they inherit capabilities and permissions, see About configuring role-based user access.
• For information about granting management access to custom roles, see Add access controls to custom roles.
• For more information about role inheritance, see Role inheritance in the About configuring role-based user access topic.
• For more information about how capabilities work, as well as the full list of capabilities, see Define roles on the Splunk platform with capabilities.

Add or edit a role

Create or edit roles for your Splunk platform instance on the Roles page in Settings.

1. Click Settings > Roles.
2. Click New Role to create a new role, or click an existing role to edit that role.

You can also edit an existing role by clicking Edit under the Actions column, then clicking Edit again in the resulting pop-up menu.

3. Enter a name for your role.
   

   Role names must use lowercase characters only. They cannot contain spaces, colons, or forward slashes. You cannot edit the names of existing roles.

4. Make adjustments to role settings by editing configurations in any of the tabs in this dialog box. See the following sections in this topic for more information about these configurations.
5. After you have made the configuration changes that you want, click Save to save the role.

The only required element of a role is its name. You do not have to complete any of the following tabs to save a role.

Specify role inheritance

Use the 1. Inheritance tab to add or change the inheritance of existing roles.

1. Click 1. Inheritance to display the contents of the Inheritance tab.
2. (Optional) In the Role Name text box, type in characters to display roles whose names contain those characters.
3. (Optional) Click the All column header to select from a menu of display options for roles: "Show selected", "Show unselected", or "Show all".
4. (Optional) Click the checkbox next to an existing role from which you want this role to inherit. You can click multiple checkboxes, or select all existing roles by clicking the checkbox in the column header.

Specify role capabilities

Use the 2. Capabilities tab to add or change the capabilities that this role holds.

1. Click 2. Capabilities to display the contents of the Capabilities tab.
2. (Optional) In the Capability Name field, type in a string to display capability names that contain the string.
3. (Optional) Click the All column header to select from a menu of display options for capabilities: "Show native", "Show inherited", "Show selected", "Show unselected", or "Show all".
4. Click the checkbox next to the capabilities that you want to assign to this role.
5. Click Save.

   Capabilities that have been inherited from other roles appear as grayed out and selected. You cannot deselect capabilities that come with inherited roles.

Specify searchable indexes for a role

Use the 3. Indexes tab to choose the indexes that the role can search, and which ones it should search by default.

You can specify both event and metric indexes. You can also specify wildcards that match more than one index. If a user with the role runs a metrics search without a specified index, the search includes results from the default metrics indexes that you assign to the role. You must select at least one index with data here if you want to be able to use the SPL Search Filter generator in the 4. Restrictions tab.

Wildcards let you specify all indexes that match the text you enter. For example, if you specify a wildcard of "index_us*," it captures all existing indexes that begin with index_us. Wildcards that you create appear in the Indexes table in alphabetical order, as selected and default indexes.

You can create multiple wildcards, but they only apply to the current role. You cannot transfer wildcards to other roles; instead you must explicitly create the same wildcard by editing the roles and adding the wildcards there. To delete a wildcard from a role, confirm that the wildcard is neither a selected nor a default index, and save the role.

How wildcard indexes affect index selection

If you create an index wildcard, any indexes that match that wildcard automatically change state based on whether or not you choose the wildcard to be "Included" or "Default". For example, if you create a wildcard called audit*, any indexes that begin with audit follow the assignment selections you make for the wildcard index. You cannot make changes to an index that is controlled by a wildcard. Splunk Web grays the checkboxes for those indexes out, and when you hover over them, a tooltip appears that tells you what wildcard covers that index. You must first remove the wildcard before you can access the indexes that the wildcard covers.

The * wildcard, which Splunk Web provides by default, covers all non-internal indexes. Internal indexes begin with an _, and do not count against your license. Choosing this wildcard to be "Included" or "Default" means that you choose all non-internal indexes to be either included or default. This includes any wildcard indexes that the * wildcard matches. If you are unable to assign a specific index or make it a default, confirm that the * wildcard does not have either option selected.

1. Click 3. Indexes to display the contents of the Indexes tab.
2. (Optional) In the Wildcards section, enter a string that contains the * character and specifies the group of indexes you want to search, then click Create.

   You can repeat this action to add more wildcards. If a wildcard already exists, Splunk Web advises you.

3. (Optional) In the Index Name field, type in a string to display index names that begin with that string.
4. (Optional) Click the All column header to select from a menu of display options for indexes: "Show native", "Show inherited", "Show selected", "Show unselected", or "Show all".
5. Click the Included checkbox for an index to include search results from that index for this role.
6. Click the Default checkbox for an index to include search results from that index when a user that holds this role does not specify an index in their search.

   Indexes from inherited roles appear as grayed out and selected. You cannot deselect indexes that come with inherited roles.

Specify search restrictions for a role

Use the 4. Restrictions tab to limit the scope of search results that return when users with the role run searches. The search filter combines with the base search that users with the role run, based on several factors. The search job returns only the results that arise from the combined search.

For more information on valid syntax to use with the search filter, see "SPL search filter syntax" later in this topic.

The walklex command does not honor role-based search filters. For this reason, people who have roles with role-based search filters cannot use walklex unless they also have a role with either the admin_all_objects capability or the run_walklex capability. These capabilities do not prevent walklex from being able to override role-based search filters.

1. Click 4. Restrictions to display the contents of the Restrictions tab.
2. In the SPL Search filter field, type in a valid SPL string that combines with any base search that a user with this role runs.
3. (Optional) Use the Search filter SPL generator to create a search filter.
1. In the Indexed fields and values time range drop down list, choose a time range to search for indexed fields and their associated values.
   

   For these controls to work, you must have selected at least one index with data in the Indexes tab. Changing the default time of 60 seconds can increase the amount of time it takes to populate the Indexed Fields and Values text boxes, but might be necessary to retrieve a comprehensive list of indexed fields.

2. In the "Indexed fields" text box, do one of the following:
1. Click on the text box to display a drop-down list box that contains the most common indexed fields that were found, based on the indexes you have selected in the 3. Indexes tab and the time that you specified in the "Indexed fields and values time range" setting. The |walklex search command populates this field.
2. Enter the name of an indexed field.

If you select an indexed field that is already present in the SPL search filter, Splunk Web displays a message about possible SPL collisions. Review the filter to confirm that there are no unintended conflicts.

3. In the "Values" text box, do one of the following:
1. Click on the text box to display a drop-down list box that shows the top 250 indexed field values that were found, in lexical order, based on the fields you selected in the "Indexed fields" text box.
2. Enter a custom field value directly. You can also use wildcards.
4. Use the Concatenation option drop-down list box to determine how the SPL generator adds SPL text that it generates to any existing text in the SPL search filter.
   1. Choose "AND" to add the generated SPL prepended with the AND keyword
   2. Choose "OR" to add the generated SPL prepended with the OR keyword.
   3. Choose "NOT" to add the generated SPL prepended with the NOT keyword.

   If the search filter does not have any text in it, the "Concatenation option" drop-down list box is disabled.

5. Review the SPL that the SPL generator proposes adding to the SPL search filter.
6. If you are satisfied with the SPL that has been generated, click Add to SPL search filter. The SPL generator updates the SPL search filter text box with the generated text. If there is already text in the filter text box, the SPL generator appends the generated text. Depending on the concatenation option you chose, the SPL generator adds the text after the "AND", "OR", or "NOT" keyword.
7. (Optional) If you do not like the SPL that you generated with the SPL generator, you can remove the text that you added by clicking Reset.
8. (Optional) If you want to see how the search filter can affect search results before you apply it, click Preview search filter results. This action opens a new Search page that shows the results of a search with the current search filter.

The search preview results are an example of what a user with this role might see. Several factors can alter the actual results from what the preview shows.

The preview makes the assumption that the user holds only this role. While it includes results from inherited indexes, it does not include any search filters that might exist in inherited roles.

If you have configured the Splunk platform instance so that search filters for a role eliminate, rather than select results, actual results might be the opposite of what you see in the preview. The srchFilterSelecting setting in authorize.conf controls whether search filters select or eliminate results, and is true by default. A false value tells search filters to eliminate results.

Specify default app and search-related limits for a role

In the 5. Resources tab, you can control the default app that a user with this role sees when they log into the Splunk platform. You can also set user- and role-based limits to concurrent searches, role-based limits to search time ranges, and limits to the amount of disk space that a person with a given role can take up with their search jobs at a given time.

You can also control various search job characteristics and limits.

1. (Optional) In the Default app dropdown, select the default Splunk app that appears when a user that holds this role logs in.
2. (Optional) In the Role search job limit section, enter the maximum number of standard searches that this role can run concurrently in the Standard search job limit text box.
   

   To remove search limits, you can enter 0 in this and other search limit text boxes.

3. (Optional) Enter the maximum number of real-time searches that a user with this role can run concurrently in the Real-time search job limit text box.
   
4. (Optional) In the User search job limit section, enter the maximum number of standard and real-time searches that a user can run concurrently in the Standard search job limit and Real-time search limit text boxes.
   

   If enable_cumulative_quota is set to true in limits.conf, role search job limits override user search job limits. For example, say you set a Role search job limit of 45 standard jobs for the Admin role, and you set a User search job limit of 10 standard search jobs. Under this condition, if you have five Admin users, they will only be able to run 45 standard search jobs concurrently as a group, not 50 standard search jobs.

5. (Optional) In the Role search time window limit section, select a standard search maximum time range for this role. Click the drop-down list box to choose a value:

   Setting	Description	Can inherited roles override this setting?
   Unset	Historical searches run by this role do not have a time range limit.	Yes
   Infinite	Historical searches run by this role do not have a time range limit.	No
   Custom time	Exposes a text box where you can define a maximum time range in seconds for historical searches run by this role.	Yes

   The Splunk platform applies custom time range limits backwards from the latest time specified for a search.
   
   If a user has multiple roles with custom time range limits, or has roles that inherit from roles with custom time range limits, the Splunk platform applies the least restrictive search time range limits to the role. For example, say you have a user named Blue who has role A with a custom time of 30s, role B with a custom time of 60s, and role C with a custom time of 3600s. Blue would get the maximum search time range of 3600s, or 1 hour.

   This setting does not apply to real-time searches.

6. (Optional) In the Disk space limit section, enter the amount of space that search jobs run by a person with this role can take up on disk at a given time in the Standard search limit text box.

Save changes to role configurations

You must save changes to role configurations (including search time restrictions) and restart the Splunk platform before those changes can take effect. If you do not restart, the instance cannot enforce your configurations and restrictions.

• To save all of the changes you have made and close the dialog box, click Save.
• If you do not want to save the changes, click Cancel.
  

  If you click Cancel, you lose any unsaved changes that you have made since you opened the Roles dialog box.

For more information about restarting the Splunk platform, see Start and stop Splunk Enterprise in the Admin Manual.

SPL search filter syntax

The SPL search filter field in the 4. Restrictions tab accepts any of the following search terms:

• source::
• host::
• index::
• sourcetype::
• eventtype= or eventtype::
• The keywords AND, OR, or NOT
• Search fields

You can enter SPL manually into the SPL search filter text box, or use the SPL generator to create SPL for the search filter based on fields and field values that you have indexed.

You can use wildcards. Use OR to allow multiple terms, or AND to make the filter more restrictive.

Caveats to using the SPL search filter

The search terms cannot include any of the following:

• Saved searches
• Time operators
• Regular expressions
• The mstats, msearch, and mcatalog search commands, when you use them in conjunction with the key::value syntax
• Any fields or modifiers that you can override from the Splunk Web search bar

Usage of search filter syntax with event and metrics data

For event data, when you specify search term filters, use the key::value syntax, rather than key=value, where possible, to restrict search terms to indexed fields. If you specify the key=value syntax as part of a filter, the search filter dialog box warns you that usage of the = operator can result in poor search performance for users who hold the role. Also, it is not secure to use the operator because filters with the operator can be bypassed by user knowledge objects.

If you attempt to add an indexed field that already exists in the current search filter, the page warns you that the indexed field already exists and to ensure that you have no unintended SPL conflicts in the search filter.

For search filters with metrics data, use the key=value to specify search restrictions to metrics fields. This is because the key::value syntax does not work for searches over metrics data. In this case, you can safely disregard syntax warnings about the = operator that the search filter dialog box presents.