Restrict Index access

[Sqig]

Hi. We are looking to restrict access to just a few of our many indexes in Splunk. In the Role rights under Access Controls, the default is for each user level to have rights to "All non-internal Indexes"

Obviously, for our default "user" group, we could specifically allow access to each individual index except those we want to restrict, but this presents a management problem when new indexes are added (we have to then update those rights to include the newly-created index on each of our Search Heads).

Is there a way to blacklist indexes? That is, "All indexes except Internal and X, Y, and Z" ?

Or are we stuck manually managing access to indexes whenever we add them?

Thanks.

[christopherr_sp]

The following previously logged Enhancement Request is related to this question.

SPL-116541 Search Index Blacklist

Add configuration parameter to authorize.conf to disallow the searching of certain indexes. This allows users to search all indexes by default, but keep certain ones blocked.

Example implementation:

[role_ninja]
srchIndexesAllowed = *
srchIndexesDenied = private_index;super_ninjas_only

[nick405060]

Has this enhancement been included in a 7.2.x release yet?

[christopherr_sp]

No, not yet.

[Akeydel]

Has this enhancement been added in 8.1.4, or 8.2.0? 

[marty_lindsay]

Hi Dave,

Is this still the same with Splunk 6? It would be great to have a blacklist of indexes to reduce the overhead of maintaining the whitelist. Ideally I'd be able to configure the user role to access all non internal indexes except for specified secure ones.

..marty

[lguinn2]

BTW, you should probably consider Search Head Pooling. One set of configuration files, shared by all the search heads, may reduce your pain. You still need to figure out your solution, but at least you won't need to copy it and manage it across all the search heads...

Configure Search Head Pooling

[GKC_DavidAnso · Accepted solution]

Judging by $SPLUNK_HOME/etc/system/README/authorize.conf.spec you can't do a blacklist like you are looking for.

Best solution:
Use deployment server to manage your Search Heads and deploy and authorize.conf to them which controls index access. You will still have to whitelist the good indexes, but you only have to do it once. This makes it far easier to keep your security consistent.

Less optimal solution:
You could test out using a Search Filter to exclude access to the index (something like index!="payroll" ), but I think you are better off to actually restrict the use of indexes.

Getting really fancy:
Distribute your indexes.conf to your indexers by deployment server too. Then to create an index you just edit the indexes.conf in the app going to your indexers and the authorize.conf in the app going to search heads and you have configured everything in one foul swoop. In one environment I am managing three search heads and four indexers in this way, and as a result I still have hair.

More info on deployment server:
http://docs.splunk.com/Documentation/Splunk/latest/Deploy/Aboutdeploymentserver

[GKC_DavidAnso]

Good point, I guess I wasn't very clear, I have updated the post now.

It sounds to me like the member doesn't want to have to maintain a whitelist across multiple search heads. The deployment server will allow them to maintain the list in a single place, and causes the administrator to evaluate who should have access to each newly created index. If you are managing indexes and search heads both from deployment server then it can all become one documented process and is more likely to be remembered (in my experience).

[_d_]

Well, i am curious to know which setting from authorize.conf your "best solution" will use for blacklisting of indexes? The member is asking for a blacklist as he/she already knows how to whitelist or to restrict users to a particular index.

[_d_]

You can use/modify authorize.conf by adding something like this:

[role_myRole]
srchFilter = "index!=blacklisted_index OR index!=myotherBlacklistedIndex"

EDIT: removed the recommendation for placing the authorize.conf under etc/system/local. The member below makes a good point about using Deployment Server to push authorize.conf out to search heads.

- please upvote if you find this answer useful