Applying a search filter (srchFilter) conditionally

[caseyra]

Hello,

I'm working on a Splunk system where we want to restrict users to certain data behind the scenes based on their role, but certain users need the ability to see all of the data without the filter when needed. Currently, the only way we can think of to do this is to set up two accounts: 1 normal account that has the search filter defined for the specific role (E.g. we set up an srchFilter rule) and 1 account that has a similar role except it doens't have the search filter defined.

We'd like to create a more user-friendly solution, but I'm not sure how. So, my first question is how is the srchFilter field applied to queries? I was thinking that it would inject the filter before the query or at least inject it as part of the initial search aspect of the query. However, I'm looking a query that was run using tstats and that's making me think my thought process is wrong. If that's the case, then are there any thoughts as to how we could do this? My only other thought is to use a custom command to implement a custom filter, but even then I think tstats would make this much more difficult if not impossible to do correctly.

Thanks.

[maciep]

I am pretty sure tstats is immune to a search filter. I had planned on building some accelerated dm's for data in a common index and limiting access by roles, but had to scrap that idea when i realized that about tstats.

it sounds to me, based on some of the other comments here, that the only reason you really need to limit the managers from seeing other team's data is because sometimes they don't want to see it. And these are the same people building their own dashboards? If they can build their own dashboards, then surely they can filter to see the data they care about in that moment right?

I'm sure that's not helpful, but there's not going to be a user-friendly way to freely swap between having access and not having access based on nothing but whims. And if you give them two accounts, they will likely use the one with all of the access all of the time anyway...because why not? Just my 2 cents as a fellow admin...because they would have just got a "no" from me 🙂

Also...maybe relevant, maybe not...this is a session from .conf last year about role based access. and if you have ideas, the presenters seemed eager for feedback and use cases.

https://conf.splunk.com/files/2017/recordings/splunking-with-multiple-personalities-extending-role-b...

[caseyra]

Yes, they want to be able to see only their data most of the time, but want to be able to see all of the data on occasion. We used roles to implement the restrictions because of the fact they can create their own dashboards. It's a sucky situation for sure and yes, I do understand your point about the accounts, but we don't have much of a choice at this time.

[nickhills]

This sounds like a perfect example of using separate indexes per department.

'Normal' users only get their departmental index, management roles get access to multiple.
https://answers.splunk.com/answers/489277/restrict-users-to-search-specific-indexes.html

[caseyra]

That would be great except we can't restructure the data at this time. There's several years worth of data in the system and trying to implement multiple indices would be a heavy burden on the system right now. We're running low on disk space as well.

So, yeah, we're stuck with what we have right now and I'm just trying to work with it as best I can.

[FrankVl]

Just to clarify: you mean that userA should normally have a restricted view, but in certain situations, the same userA needs to be able to see the events without restrictions?

If the "when needed" does not occur very often, you could consider switching the user's role when needed, but that would require the user to get help from an admin. More user friendly as the user does not have to switch to a different account, but it does introduce a dependency on the admin to switch the user to the 'unrestricted' role.

Then again: any solution where the user can freely choose whether or not to have the restrictions enabled or not is a bit pointless, isn't it? I mean: what's the point of having a restriction in place if the user himself can disable that restriction?

[caseyra]

Yes, you got it right. It's an odd case, but the good news is that it's only for a select few users. E.g. managers. It's just that they normally need to look at only their departments data, but sometimes the want to see data for all of the departments.

[FrankVl]

Can you not solve that by presenting them some department specific reports/dashboards, or do they really actively use the search to dig through their department's data normally?

Should the access really be restricted normally, or is it just to help them focus on their own department's data? In that latter case, you could also provide them with a search macro that applies the filter in a user friendly manner perhaps? Such that they can use that macro when they only want to look at their own data and when they want to look at other data, they leave the macro out (or use the macro relevant for that other department).

[caseyra]

First, they really want to use the same dashboards for all of the data. Even then, yes, they perform searches against the data to build the dashboards they want. We, the admins, don't build the dashboards. However, we have to make sure that people only see what they're allowed to see.

As for the macro, that's an interesting idea, but I'm not sure it will work in our use case as we're supporting the different departments, hence why we're using roles to restrict who can see what. If a person switches departments, we need to make sure their roles are updated correctly so they now can't see their old department but can see their new department.

Edit: Even then, we don't want people who shouldn't see all of the data "forget" to put the macro into their queries. Out of, let's say 100 users, only maybe 5 need to be able to see all of the data.

[FrankVl]

Well, those people that do not need to see data from other departments, can simple be put in a role that restricts them. The few people (managers) that do need to see data beyond their own department can be put in a role that is not restricted.

To make it easier for managers to still only look at their own department's data you provide them with a macro.