srchFilter usage in backend with multiple roles

[Karthikeya]

We will create two indexes per application one for non_prod and one for prod logs in same splunk. They create 2 AD groups (np and prod). We will create indexes, roles and assign that to respective AD groups. Till here it is good. 

Now we created a single summary index for all prod indexes data and we need to give access to that index to all app teams. Being single summary index, thought of filtering it at role level using srchFilter and service field, so that to restrict one user seeing other apps summary data

Below is the role created for non-prod

[role_abc]
srchIndexesAllowed = non_prod
srchIndexesDefault = non_prod

Below is the role created for prod 

[role_xyz]
srchIndexesAllowed = prod;opco_summary
srchIndexesDefault = prod
srchFilter = (index::prod OR (index::opco_summary service::juniper-prod))

 Not sure whether to use = or :: here to work? Because in UI when I m testing it is giving warning when I give = .. but when giving :: search preview results not working. Not sure what to give?

Here my doubt is when the user with these two roles if they can search only index=non_prod if he see results or not? How this search works in backend? Is there any way to test? And few users are part of 6-8 AD groups (6-8 indexes). How this srchFilter work here? Please clarify 

[Karthikeya]

Is there any way that I can get rid of double quotes? And one more thing I noticed, if user has access to 10 roles (10 indexes) and we have applied srchFilter to 6 roles, then if they are searching with other 3 indexes (which are not there in srchFilter), he is not seeing any results. It means, if I use srchFilter by default I need to include it's index name in srchFilter? srchFilter is getting added for all the roles with OR...

[PickleRick]

No, I don't think you can modify the behaviour of the collect command and hence the output event format (much). And yes, you'd have to do some magic like

index!=your_specific_index OR (index=your_specific_index AND <additional conditions...)

Ugly, isn't it?

[Karthikeya]

Why can't I give srchFilter as the role index by default? What will be the drawback for this? For prod roles I need to mention summary index condition as well with their restricted service... How @splunklearner told.. exactly the same way..

Below is the role created for non-prod

[role_abc]

srchIndexesAllowed = non_prod

srchIndexesDefault = non_prod

srchFilter = (index=non_prod)

Below is the role created for prod

[role_xyz]

srchIndexesAllowed = prod;opco_summary

srchIndexesDefault = prod

srchFilter = (index=prod) OR (index=opco_summary AND (service=juniper-prod OR service=juniper-cont)))

[PickleRick]

Yes, you _can_ do that. It's just that managing search filters is less convenient and thus maintenance of search filters is less straightforward than simply selecting index access per role using normal "allowed index" functionality. And you're still using search-time fields for limiting access and those search-time fields can be overriden by your users. There's no way around that as long as you don't have indexed fields to search by.

To be fully honest - you already seem to have a relatively convoluted data architecture (judging from what you're saying) and you're stuck on building on top of that unless you do some rearchitecting, which might need quite a lot of effort. That's the point when you should engage an experienced consultant to take a look at your environment and your requirements and give you a more holistic analysis and recommendations.

We can give you hints about how Splunk works and what _can_ be done with it but we won't tell you what you _should_ do in the end because we don't know the whole picture and we're not taking responsibility for the final decisions.

[Karthikeya]

Thanks will this be more secure than before? 

[livehybrid]

Hi @Karthikeya 

Regarding "service::juniper-prod" - This will only work if service is an indexed field as :: is used to reference an indexed field. 

@richgalloway makes some good points - srchFilters can get very complicated very quickly - Ive seen this implemented for production environments before and ended in lots of stress. All it takes is someone to get an additional role with a more permissive srchFilter and it all breaks down.

In terms of your question about OR/AND, check out this:

srchFilterSelecting = <boolean>
* Determines whether a role's search filters are used for selecting or
eliminating during role inheritance.
* If "true", the search filters are used for selecting. The filters are joined
with an OR clause when combined.
* If "false", the search filters are used for eliminating. The filters are joined
with an AND clause when combined.
* Example:
* role1 srchFilter = sourcetype!=ex1 with selecting=true
* role2 srchFilter = sourcetype=ex2 with selecting = false
* role3 srchFilter = sourcetype!=ex3 AND index=main with selecting = true
* role3 inherits from role2 and role 2 inherits from role1
* Resulting srchFilter = ((sourcetype!=ex1) OR
(sourcetype!=ex3 AND index=main)) AND ((sourcetype=ex2))
* Default: true

🌟 Did this answer help you? If so, please consider:

• Adding karma to show it was useful
• Marking it as the solution if it resolved your issue
• Commenting if you need any clarification

Your feedback encourages the volunteers in this community to continue contributing

[richgalloway]

Avoid search filters.  While they can be useful at times, more often they complicate matters.  For instance, in your case the members of 6-8 AD groups (therefore, presumably, in 6-8 Splunk roles) will have 6-8 search filters combined with implicit AND operators to create a search that finds nothing.

The only reliable way to control access to data is to put that data in an index with the proper RBAC settings.  Rather than have a single summary index, it would be better to create a separate summary index for each group of users with unique access requirements.

[Karthikeya]

@richgalloway I have read somewhere that it will be implicit OR. May be in documentation can't remember.

But is it good practice to have summary data into original index? What are the consequences I face in long term? Sourcetype is stash I see for summary data. Not able to change this. 

[PickleRick]

The :: notation is for indexed fields. If a field is defined as indexed field, the k=v part in the search will get translated to a condition using k::v form in the underlying index search phase.

While index is not an indexed field as such both forms should work with it as well.

To get a bit more technical - indexed fields are written as single key::value tokens in the lexicon so you can look for them by those tokens.