We have one index on our indexer cluster that has sensitive data. We want to set up a standalone search head that has additional security requirements (using RSA tokens/OTP for 2-factor authentication) that has access to the sensitive index plus all of the other indexes. The challenge is that we want to set up all of our other search heads (1 cluster, several other standalones) to NOT be able to search on the sensitive index at all.
We thought about using a search filter in the default role like "index != sensitive" but we're not sure if that will impact search performance. Also we don't know if that would prevent admin users from searching on the sensitive index. Also if a role is given access to "all non-internal indexes" would that open up access to the sensitive index?
It is not possible. When a Search Head peers to an Indexer, it gets EVERYTHING. Sure, you can institute RBA but if an admin who controls this decides to allow it, you get it. HOWEVER, I was talking to @cgales at .conf 2017 in one of the sneak-peek beta demo rooms (I forget the name of the area but you have to sign NDAs to go in) there was a project that Chris was demonstrating that had, as a component, the capability to do this. So if this project gets launched, at some point there will be a way to do this. But for now, it is impossible.
@woodcock - nope, it wasn't me...was it Chris Green?
ARGHHHH! You are correct. I talked to SOOOOOO many people! It was actually Clint Sharp @coccyx. Maybe he can elaborate on future options(ish).
Hi @lemmons2,
There are 2 options you can achieve this.
1.) Assign only required indexes to role but in that case when you will create new indexes in your environment you need to add those new indexes every time in respective roles.
2.) Option which you have suggested to blacklist sensitive
index in srchFilter
. Regarding performance question & if a role is given access to "all non-internal indexes", when you check search.log
for particular job before and after applying search filter for query index=*
it looks like this, without search filter remoteSearch=litsearch index=*
and with search filter remoteSearch=litsearch (index=* index!=sensitive)
so in this case splunk will add whatever given in search filter as AND in main query so if you will assign "all non-internal indexes" with search filter user will not able to able search sensitive data but Admin will able to search all the data until and unless you restrict search filter in admin role but any admin can revert back easily so not full proof restriction. And based on documentation splunk suggest not to use !=
OR NOT
in query because when you will use !=
it tries to check all result and filter out NOT equal to which impact search performance.
So I'll recommend to use option 1.