topic Re: srchFilter usage in backend with multiple roles in Splunk Search

srchFilter usage in backend with multiple roles

Karthikeya — Fri, 25 Jul 2025 18:42:50 GMT

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

Re: srchFilter usage in backend with multiple roles

PickleRick — Fri, 25 Jul 2025 20:25:47 GMT

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.

Re: srchFilter usage in backend with multiple roles

richgalloway — Fri, 25 Jul 2025 20:43:08 GMT

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.

Re: srchFilter usage in backend with multiple roles

Karthikeya — Sat, 26 Jul 2025 06:01:38 GMT

@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.

Re: srchFilter usage in backend with multiple roles

livehybrid — Sat, 26 Jul 2025 06:17:36 GMT

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

Re: srchFilter usage in backend with multiple roles

Karthikeya — Sat, 26 Jul 2025 08:27:18 GMT

@richgalloway @PickleRick I checked in chatgpt and explored authorise.conf and thought of using below. Please check and verify and let me know will it works --

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)

Still confused on = and :: index and service both are not indexes fields hence used =.

Re: srchFilter usage in backend with multiple roles

PickleRick — Sat, 26 Jul 2025 09:29:12 GMT

For a search-time field you cannot use the :: syntax.

Re: srchFilter usage in backend with multiple roles

Karthikeya — Sat, 26 Jul 2025 09:33:20 GMT

Ok hence I given = for service and index. Hope it will work. Stanzas I have given will it work as expected or srchFilter has any behaviour that can't be defined?

Re: srchFilter usage in backend with multiple roles

PickleRick — Sat, 26 Jul 2025 19:17:38 GMT

Using search-time fields in search filters for limiting user access can be easily bypassed.

Search filter(s) for role(s) generate(s) additional condition or set of conditions which is/are added to the original search. So - for example - your user searches for

index=windows

and his role has search filter for

EventID=4648

the effective search spawned is

index=windows EventID=4648

And all seems fine and dandy - a user searches only for the given EventID. But a user can just create a calculated field assigning a static value of 4648 to all events. And all events will match the search filter and all events (even those not originally having EventID=4648) will be returned.

So search filters should not (at least not when used with search-time fields) be used as access control.

Re: srchFilter usage in backend with multiple roles

Karthikeya — Sun, 27 Jul 2025 03:33:01 GMT

@PickleRick ok and how this will be applicable in my case? If I restrict them based on service for summary index, even if he give |stats count by service he cannot see other's services data right? What else can he do here?

Re: srchFilter usage in backend with multiple roles

Karthikeya — Sun, 27 Jul 2025 04:14:21 GMT

cat props.conf

[opco_sony]

TIME_PREFIX = ^

MAX_TIMESTAMP_LOOKAHEAD = 25

TIME_FORMAT = %b %d %H:%M:%S

SEDCMD-newline_remove = s/\\r\\n/\n/g

LINE_BREAKER = ([\r\n]+)[A-Z][a-z]{2}\s+\d{1,2}\s\d{2}:\d{2}:\d{2}\s

SHOULD_LINEMERGE = False

TRUNCATE = 10000

# Leaving PUNCT enabled can impact indexing performance. Customers can

# comment this line if they need to use PUNCT (e.g. security use cases)

ANNOTATE_PUNCT = false

TRANSFORMS-0_fix_hostname = syslog-host

TRANSFORMS-1_extract_fqdn = f5_waf-extract_service

TRANSFORMS-2_fix_index = f5_waf-route_to_index

cat transforms.conf

# FIELD EXTRACTION USING A REGEX

[f5_waf-extract_service]

SOURCE_KEY = _raw

REGEX = Host:\s(.+)\n

FORMAT = service::$1

WRITE_META = true

# Routes the data to a different index-- This must be listed in a TRANSFORMS-<name> entry.

[f5_waf-route_to_index]

INGEST_EVAL = indexname=json_extract(lookup("service_indexname_mapping.csv", json_object("service", service), json_array("indexname")), "indexname"), index=if(isnotnull(indexname), if(isnotnull(index) and match(index, "_cont$"), index, indexname), index), service:=null(), indexname:=null()

cat service_indexname_mapping.csv

service,indexname

juniper-prod,opco_juniper_prod

juniper-non-prod,opco_juniper_non_prod

This is the backend query to route logs from global index to seperate indexes through service name. How to make this service field as indexed field?

Re: srchFilter usage in backend with multiple roles

PickleRick — Sun, 27 Jul 2025 06:18:16 GMT

In your case the user can define his own field which will always have the value matching that of search filter.

The simplest way to do so would be to create a calculated field

service="your service"

And if you rely in your search filter on service="your service" condition - well, that condition will be met for all events effectively rendering this part of the filter useless.

Re: srchFilter usage in backend with multiple roles

Karthikeya — Sun, 27 Jul 2025 06:34:04 GMT

@PickleRick then if I do service as a indexed field.. will it solve my problem or is there any chance that this can be violated at some point?

Re: srchFilter usage in backend with multiple roles

PickleRick — Sun, 27 Jul 2025 12:04:13 GMT

Wait a second. You're doing summary indexing. That means you're saving your summary data as stash sourcetype. It has nothing to do with the original sourcetype - even if your original sourcetype had service as indexed field, in the summary events it will be a normal search-time extracted field.

And generally you shouldn't fiddle with the default internal Splunk sourcetypes.

Re: srchFilter usage in backend with multiple roles

Karthikeya — Sun, 27 Jul 2025 12:20:47 GMT

@PickleRick sir what can I do now? I am breaking my head. Is there no option left other than creating seperate summary index per app? If yes, can I ingest the respective summary index to same app index (appA index -- opco_appA summary index also opco_appA?

Re: srchFilter usage in backend with multiple roles

PickleRick — Sun, 27 Jul 2025 12:28:57 GMT

It's not that you can't do this or that. It's just that using search filter is not a sure method of limiting access. Noone forbids you from doing that though. Just be aware that users can bypass your "restrictions".

Also you technically can edit the built-in stash sourcetype it's just very very very not recommended to do so.

As I said before - you can index the summary back into the original index but it might not be the best idea due to - as I assume - greatly different amount of summary data vs. original data.

So the best practice is to have a separate summary index for each group you have to grant access rights separately. There are other options which are... technically possible but noone will advise them because they have their downsides and might not work properly (at least not in all cases).

Asking again and again doesn't change the fact that the proper way to go is to have separate indexes. If for some reasons you can't do that, you're left with the already described alternatives of which each has its cons.

Re: srchFilter usage in backend with multiple roles

splunklearner — Tue, 29 Jul 2025 16:12:54 GMT

You can give in this way and test and it will some how work. but this is not secure you know.

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 ))

I think this can help you.

Re: srchFilter usage in backend with multiple roles

Karthikeya — Tue, 29 Jul 2025 17:12:34 GMT

@PickleRick will this work for me? What @splunklearner given...

Re: srchFilter usage in backend with multiple roles

PickleRick — Tue, 29 Jul 2025 17:26:06 GMT

As I said before - you _can_ use search-time fields but your users can bypass it if they know about it and know how.

Re: srchFilter usage in backend with multiple roles

Karthikeya — Tue, 29 Jul 2025 18:20:46 GMT

@PickleRick ok got it. So the secure one will be creating seperate index for application wise. But we have nearly 500 indexes to come in overall scope and as of now we have created 100+ indexes which means 50 apps (non-prod and prod 2 indexes per app).. if I create summary indexes for these it would be more indexes again. Ideally how many indexes should be there in an environment? However we are using volumes and smartstore as well. Is it very difficult to manage these indexes in future?