Topics

| pdf version

How Splunk Works

Granular Access Control


Splunk > The IT Search Company

  • Search and navigate IT data from applications, servers and network devices in real-time.
  • Download Splunk

Localized Splunk documentation

Looking for Splunk documentation in other languages?

Configure access controls

This documentation does not apply to the most recent version of Splunk.

This documentation applies to the following versions of Splunk: 3.1 , 3.1.1 , 3.1.2 , 3.1.3 , 3.1.4

Configure access controls

You can configure access controls for different users and data by editing access_controls.conf.


Granting access through roles

A role is a name followed by a search that defines the allowed data. The search can include:


  • source::
  • host:: and host tags
  • eventtype:: and event type tags
  • search fields
  • wildcards

The search terms cannot include:


  • indexes
  • sourcetypes
  • saved searches
  • time operators
  • regular expressions
  • any fields or modifiers SplunkWeb will overwrite

Roles can be any search that meets these criteria. Keep in mind that AND terms are a more efficient search than OR terms. Adding multiple roles to a group is essentially adding OR conditions, so it is better to have a role which defines your desired access as closely as possible rather than apply many roles to the same group. Minimize the number of OR conditions to improve performance.


Users, groups and roles

Access controls are defined based on users, groups and roles:


  • A user is a Splunk user.
  • A user can belong to multiple groups.
  • A group may have multiple roles.
  • A role is a search that follows the specification listed above.

Please note: an access_controls.conf group is not associated with LDAP groups in Splunk 3.X. That is, Splunk will not look in LDAP for group names and membership even if you are using LDAP as your Splunk authentication method.


Configuration

Edit $SPLUNK_HOME/etc/bundles/local/access_controls.conf.


Add a role stanza, defining the various searches that will be approved.


[roles]
roleA = $VALID_SEARCH_STRING
roleB = $VALID_SEARCH_STRING2
...

Next, add a group stanza, mapping groups to the roles you've created.


[groups]
fooGroup = roleA
barGroup = roleA roleB, etc
...

Finally, add a user stanza, specifying which users belong to which groups:


[users]
Jack, Kate, John = fooGroup
Ben, Juliet = barGroup
... 

Example

A simple example to illustrate the user, group, role definitions:


[roles]
roleA = source::/var/log/system.log*
roleB = host::sullivans-computer*
[groups]
systemGroup = roleA 
financeGroup = roleB roleA
[users]
Joe = systemGroup
kathleen = financeGroup

Joe is a Splunk user who is a member of the systemGroup. The systemGroup has one role defined, roleA. roleA allows access to the source files, /var/log/system.log. A wildcard is used to allow access to all the associated system log files in that directory. kathleen is a member of the financeGroup. The financeGroup belongs to two roles. roleB grants access to all events with the host:: sullivans-computer*. roleA grants access to the source files /var/log/system.log*. The combination of the roleA and roleB allows access to all events on host::sullivans-computer and access to source::/var/log/system.log* events regardless of host. The events that can be accessed are those you can see with the search:


source::/var/log/system.log OR host::sullivans-computer

All other Splunk users have no restrictions.

Revision: 207 | Contact | Privacy Policy | Terms of Use | Community content licensed under Creative Commons