What is the Precidence for Excluding an Index from a Role Using the GUI?

[I_am_Jeff]

I have just a few search heads to manage. (version 4.3.4) A few are pooled, one is not. I'd like to exclude indexes from certain roles. Say this is the desired situation.

1. Power users cannot search/access the accounting and legal indexes.
2. Legal role can search legal indexes, but not accounting indexes.
3. Accounting role can search accounting indexes, but not legal indexes.

Working through the GUI Splunk > Manager > Access controls > Roles I find the Search restrictions and Indexes sections where I can restrict or grant a role access to an index.

I've been using Indexes section to exclude an index from a role, but the logic is biased towards listing all allowed indexes. If I add an index, I have to circle back and verify everyone has access to the new index. Can I do something like this in the Search restrictions section and completely ignore the Indexes section?

• In my power user role, enter:

  index=* NOT (index=legal OR index=accounting)

• In my legal role, which inherits power, enter:

  index=* NOT index=accounting

• in my accounting role, which inherits power, enter:

  index=* NOT index=legal

In my case it works well if I can configure by listing the restricted indexes instead of listing the allowed ones.

If I have to use both the Indexes and Search restriction sections, say to also configure access to the internal indexes, how do they interact? Does one section override the other? Do the rules get merged? (If so, how?) Should I avoid using both sections at all costs? Are there hidden costs to using these strategies?

[aholzer · Accepted solution]

The "Search restrictions" section gets applied on top of the indexes section you select for a role. If you say Role A has access to index 1 and 2, and add the restriction section "index=1", then any user with Role A, will only have access to index 1, because the restriction will get applied to the results of his searches.

It sounds like you are trying to simplify your life by just saying All internal and All non-internal indexes (in the index section), which would normally give a role full access to all indexes, and then applying specific Search restriction. This method should work, you can always create test users and grant them the specific role you are changing and see if the results are what you expect. One down side to this method is if you forget to apply the proper restrictions, the users will have full access to all your data.

So to answer all your questions:

• If I have to use both the Indexes and Search restriction sections, say to also configure access to the internal indexes, how do they interact? The Search restrictions get applied on top of the indexes section. This section is normally used for things other than index, like sourcetype or source.
• Does one section override the other? They work together. The index section indicates what indexes are available to a user, while the restriction section applies some behind the scenes search parameters
• Do the rules get merged? (If so, how?) See answers for both questions above
• Should I avoid using both sections at all costs? No
• Are there hidden costs to using these strategies? You are merely adding more elements to the start of your search by adding "search restrictions". This, if done correctly, should only help improve the run time of your searches, since they will have less results to wade through.
• Perhaps I should not use "index=*" as that might try to include all indexes instead of just "main" or a user-specified index? It's probably a good idea to specify the indexes that you want the role to have access to specifically rather than index=*. Example: index=accounting index!= legal

Hope this helps

[I_am_Jeff]

Perhaps I should not use "index=*" as that might try to include all indexes instead of just "main" or a user-specified index?