Is there a way to filter out events from search results based on the logged-in Splunk user running the search and specified field values?

[robburns]

I have a requirement to filter out events based on:

1. the USER running the search and
2. FIELD VALUES contained in the event

I don't want certain users to see certain events based on a field value. For example, if I have this set of events:

PartID  Company     Cost    Count   Category
-------   -----------   -------  -------  --------
P1      X Corp      111.11  10      ABC
P2      ABC Biz     222.22  20      ABC
P3      Parts Inc    333.33 30      DEF
P4      Stuff LLC    444.44 40      GHI

And user "maxfoo" logs into the Splunk server, he should only be allowed to see 3 events with (Category=ABC | Category=DEF). He should NOT able to see the Category=GHI event.

Are there any efficient ways to implement something like this?
Thanks!

[somesoni2]

Is the user maxfoo sees this data only OR it has access to other data/indexes?

[robburns]

Hi somesoni2 -- No, there are many users with access to various categories. The users may also have access to other datasets with the same categories, so we'd like to reuse a solution across our system.

[diogofgm]

I had a situation where i needed to do something like that. the solution i found, since user roles can define access to certain indexes was to split the data in to more than 1 index. My contained audit data mixed with other data. The other data was available to everyone but the audit data should only be available to a certain group.
So i created 2 indexes:

• my_index
• my_index_audit

So when searching i used:

index=my_index*

For users that have permissions to look in both indexes this will get them the all the data. For the remaining users this will return only results my_index data.

To split the data, just use transforms to forward data one way or another depending on the rules you set. In your case the category.

props.conf

[your_sourcetype]
TRANSFORMS-splitdata=split1,split2

transforms.conf

[split1]
SOURCE_KEY=field:category
REGEX=^ABC
DEST_KEY=_MetaData:Index
FORMAT=my_index_abc

[split2]
SOURCE_KEY=field:category
REGEX=^DEF
DEST_KEY=_MetaData:Index
FORMAT=my_index_def

There is also another benefit for splinting the data this way: data retention periods. With different indexes you can define different retention periods. In my case audit data needed to be available for 5 years but the other data just for 6 months.

This may not be the best solution if you want to manage data visibility for a big number of roles since you'd end up with a big number of indexes, but for a small number of roles its a simple solution that works.

[robburns]

Thanks. That's an innovative solution, diogofgm. I'm tempted to try prototyping it, but I do have some concerns. As you say, having a large number of different "audit" Categories leads to a lot of indexes. And in this case, we will have quite a number of Categories and roles, so I'm not sure if it will be feasible.

I'm aware that we can force additional filters to the end of user queries. So, I was hoping that we could filter out the categories each user should not see. But I'm not sure how to do this on a per user basis.