Getting Data In

How to filter access to data inside same index to different roles? Summary Index? Search Filter? Other options?

dmbuhler
Engager

Hi everyone,

I am in the need to find a way to filter data that specific roles access inside an index.

For example:

  • Index=servers
  • The index has servers from windows, linux, and ostype3
  • We want to have the following:
    • roleA has access to index=servers (but just sees windows servers)
    • roleB has access to index=servers (but just see linux servers)
    • roleC has access to index=servers (but just see ostype3 servers)

This can be achieved by using search filters and it worked ok.
However...
If then, I have a role that can:

  • RoleD has access to index=servers (but just see windows servers) 
  • RoleD has access to index=firewalls

This then will not work for roleD. RoleD will not be able to search for the index=firewalls, as the search filters takes precedence and limits the user just to see the data in:

  • RoleD has access to index=servers (but just see windows servers) 

 

So, I'm trying to find a new solution that can allow me to do what I need to, and summary index came to the idea.

However I'm struggling with something.

When my data is sent to the summary index, it's sourcetype is changed to stash. And then my data is not parsed as is in the original index.

Lets suppose I change the sourcetype from stash to original sourcetype, that then will make me use a lot more license and double it up.

So, that's why I'm asking here for help. What solutions do I have? Am I missing something or doing something wrong?

Thanks in advance if someone can help me on this. 🙂

 

Labels (2)
0 Karma
1 Solution

richgalloway
SplunkTrust
SplunkTrust

Yes, the options aren't great.  I strongly urge you to consider option #3, however.  You're correct about it applying only to new data, but you can use the collect command to copy events to the new indexes (consuming license, of course).

---
If this reply helps you, Karma would be appreciated.

View solution in original post

richgalloway
SplunkTrust
SplunkTrust

You've discovered why I don't recommend search filters.

A summary index might work.  You can get around the parsing problem by assigning a sourcetype other than 'stash' to the summary events.  That will count against your ingest license, however.

The better solution is to have separate indexes for each role's data.  Access is one of the criteria for creating a new index for data (retention and size management are the others).  If you don't want to or can't change the inputs, then consider using Ingest Actions to filter the server data to the proper index.

---
If this reply helps you, Karma would be appreciated.

dmbuhler
Engager

Ha!
So basically I have no solution.

  1. Search Filters - Not a solution, because one role affects the others.
  2. Summary Index - No solution because I will need to change the sourcetye which will consume me more license
  3. Change my indexing - to send the data to different indexes (might work) but only for new data, and will also escalate even more the number of indexes that we manage.

Option 3, might only be the new option, but I don't know if that makes much sense.

But thank you @richgalloway .

 

 

0 Karma

richgalloway
SplunkTrust
SplunkTrust

Yes, the options aren't great.  I strongly urge you to consider option #3, however.  You're correct about it applying only to new data, but you can use the collect command to copy events to the new indexes (consuming license, of course).

---
If this reply helps you, Karma would be appreciated.
Get Updates on the Splunk Community!

What's new in Splunk Cloud Platform 9.1.2312?

Hi Splunky people! We are excited to share the newest updates in Splunk Cloud Platform 9.1.2312! Analysts can ...

What’s New in Splunk Security Essentials 3.8.0?

Splunk Security Essentials (SSE) is an app that can amplify the power of your existing Splunk Cloud Platform, ...

Let’s Get You Certified – Vegas-Style at .conf24

Are you ready to level up your Splunk game? Then, let’s get you certified live at .conf24 – our annual user ...