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!

Adoption of RUM and APM at Splunk

    Unleash the power of Splunk Observability   Watch Now In this can't miss Tech Talk! The Splunk Growth ...

Routing logs with Splunk OTel Collector for Kubernetes

The Splunk Distribution of the OpenTelemetry (OTel) Collector is a product that provides a way to ingest ...

Welcome to the Splunk Community!

(view in My Videos) We're so glad you're here! The Splunk Community is place to connect, learn, give back, and ...