About configuring role-based user access
For more information about users, see About user authentication.
- admin: this role is intended for administrators who will manage all or most of the users, objects, and configuration and comes predefined with the most assigned capabilities.
- power: this role can edit all shared objects (saved searches, etc) and alerts, tag events, and other similar tasks.
- user: this role can create and edit its own saved searches, run searches, edit its own preferences, create and edit event types, and other similar tasks.
- can_delete: This role allows the user to delete by keyword. This capability is necessary when using the delete search operator.
- sc_admin (Cloud only): This role allows users to create users and roles but does not grant any other admin capabilities.
You can also create custom roles and assign your users to those roles. When you create a custom role, you determine the following:
- Allowed searches: you can define the searches that a user assigned to the role is allowed to perform.
- Role inheritance: you can have your role inherit certain properties of one or more existing roles. Role inheritance is discussed later in this topic.
- Assign capabilities: you can specify the allowed actions (change their password, change forwarder settings, etc) of the user assigned to the role. See About defining roles with capabilities for more information.
- Set allowed and default indexes: you can limit access to specific indexes and set the index that is searched by default.
As a rule, members of multiple roles inherit properties from the role with the broadest permissions.
How users inherit search filter restrictions
You can create roles that inherit the characteristics of other roles. Users assigned to multiple roles inherit properties from the assigned roles.
In the case of search filters, if a user is assigned to roles with different search filters, the filters are all combined and thus the restrictions of each role are applied.
For example, by default, the Power and User roles do not have search filters defined to restrict searches. If a user has a combination of these roles and another role with filters defined (for example,
srchFilter=x), the user will inherit the restrictions of that role, despite the association with roles that have no filter.
How users inherit allowed indexes
In the case of allowed indexes, the user is given the highest level of access granted to any role to which they are assigned.
For example, if a user is assigned to the role "simple user" which limits access to one particular index, and also to a role "advanced user" which has more capabilities and allows access to all indexes, the user will have access to all indexes. If you wanted to grant the capabilities of the "advanced user" but continue to limit their index access to the single index defined for the "simple user", you should create a new role specifically for that user.
How users inherit capabilities
In the case of capabilities, the user is given the highest level of abilities granted to any role to which they are assigned.
For example, if a user is assigned to the role "admin" which has the most capabilities, and also to a role "advanced user" which a different set of capabilities, the user will have the capabilities of both roles.
About user authentication
About defining roles with capabilities
This documentation applies to the following versions of Splunk® Enterprise: 5.0, 5.0.1, 5.0.2, 5.0.3, 5.0.4, 5.0.5, 5.0.6, 5.0.7, 5.0.8, 5.0.9, 5.0.10, 5.0.11, 5.0.12, 5.0.13, 5.0.14, 5.0.15, 5.0.16, 5.0.17, 5.0.18, 6.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 6.0.5, 6.0.6, 6.0.7, 6.0.8, 6.0.9, 6.0.10, 6.0.11, 6.0.12, 6.0.13, 6.0.14, 6.0.15, 6.1, 6.1.1, 6.1.2, 6.1.3, 6.1.4, 6.1.5, 6.1.6, 6.1.7, 6.1.8, 6.1.9, 6.1.10, 6.1.11, 6.1.12, 6.1.13, 6.1.14, 6.2.0, 6.2.1, 6.2.2, 6.2.3, 6.2.4, 6.2.5, 6.2.6, 6.2.7, 6.2.8, 6.2.9, 6.2.10, 6.2.11, 6.2.12, 6.2.13, 6.2.14, 6.2.15, 6.3.0, 6.3.1, 6.3.2, 6.3.3, 6.3.4, 6.3.5, 6.3.6, 6.3.7, 6.3.8, 6.3.9, 6.3.10, 6.3.11, 6.3.12, 6.3.13, 6.3.14, 6.4.0, 6.4.1, 6.4.2, 6.4.3, 6.4.4, 6.4.5, 6.4.6, 6.4.7, 6.4.8, 6.4.9, 6.4.10, 6.4.11, 6.5.0, 6.5.1, 6.5.1612 (Splunk Cloud only), 6.5.2, 6.5.3, 6.5.4, 6.5.5, 6.5.6, 6.5.7, 6.5.8, 6.5.9, 6.5.10, 6.6.0, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 6.6.7, 6.6.8, 6.6.9, 6.6.10, 6.6.11, 6.6.12, 7.0.0