Deployment Architecture

Does search head have impact on the indexers cluster?

omerl
Path Finder

Hello,

I have an indexers cluster, used to index data from multiple sources.
I also have multiple groups of clients, each group searches over some of the data, and uses different apps.

I figured out that the simplest way to manage those groups of clients is to create a different Search Head for each group, and letting it install any apps required, adding local indexes and lookups.

So for my comfort, giving each group admin account for its Search Head would be the easiest, but if I do so - would it be possible to manipulte / delete / have any impact on the indexes cluster data?

I'm aware of the delete1 command, which mark data as deleted, and I'm worried about its (and maybe other commands/options) impact on my indexes cluster.

Is it safe for me to give the users admin permissions? Do you have any suggestions?

Thanks!

0 Karma
1 Solution

traxxasbreaker
Communicator

Since data access permissions are all controlled by the search heads, giving multiple groups admin on their own search heads will let them access any indexes. They will also have the capability to delete for any indexes... even if you don't give this to them explicitly, if they have admin permissions they can give themselves delete permissions and potentially delete data in other indexes that they shouldn't be touching. You also generally don't want users creating their own local indexes on the search heads since your search heads would generally forward to the indexer cluster and that is where the indexes would need to be defined anyway.

You'll also want to consider the number of groups you have relative to the size of your indexer cluster. If you have too many search heads for the number of indexers that you have, you might hit some performance problems. Since it's the search heads that manage the scheduling and those search heads aren't aware of one another, the indexers would be getting hit with multiple schedulers and might become less responsive to searches overall.

Unless you're running ES, at which point you'll need a separate search head anyway, you should look at creating different roles for each group and then permission the apps based on those roles to effectively segregate the users. If there's an app that multiple groups want to use, you could have different roles that access that app and only let them share content within the same role. This way you're only managing permissions in one place and if one set of users develops something useful that can be leveraged by others, all you need to do is permission their content differently to let others leverage it rather than coping it between environments.

View solution in original post

traxxasbreaker
Communicator

Since data access permissions are all controlled by the search heads, giving multiple groups admin on their own search heads will let them access any indexes. They will also have the capability to delete for any indexes... even if you don't give this to them explicitly, if they have admin permissions they can give themselves delete permissions and potentially delete data in other indexes that they shouldn't be touching. You also generally don't want users creating their own local indexes on the search heads since your search heads would generally forward to the indexer cluster and that is where the indexes would need to be defined anyway.

You'll also want to consider the number of groups you have relative to the size of your indexer cluster. If you have too many search heads for the number of indexers that you have, you might hit some performance problems. Since it's the search heads that manage the scheduling and those search heads aren't aware of one another, the indexers would be getting hit with multiple schedulers and might become less responsive to searches overall.

Unless you're running ES, at which point you'll need a separate search head anyway, you should look at creating different roles for each group and then permission the apps based on those roles to effectively segregate the users. If there's an app that multiple groups want to use, you could have different roles that access that app and only let them share content within the same role. This way you're only managing permissions in one place and if one set of users develops something useful that can be leveraged by others, all you need to do is permission their content differently to let others leverage it rather than coping it between environments.

krusty
Contributor

So far, that sound good, but how do you set such a configuration up? In my case I have 2 indexers which are working in a cluster. My SH is also the ClusterMaster. I it could be even nicer but I do not have more machines yet. 😞
I try to configure the roles for differnet groups on the search head but unfortunately I couldn't see the created indexes in the web gui. Is there a way to make them visible there?
By the way, the indexer cluster is working fine. Events are coming in and are indexed fine.

0 Karma

omerl
Path Finder

The scheduling is a problem I didn't think about, but regarding the delete command - as far as I know it doesn't delete the data, just marking it so it won't show up on searches. Am I wrong about it?

0 Karma

gjanders
SplunkTrust
SplunkTrust

While that is correct, it would still appear invisible to all searches and is therefore "deleted" from the view of anyone searching for the required data...!

It would make it extremely easy for someone to hide data they didn't want anyone else to see within the Splunk interface.

0 Karma

omerl
Path Finder

Ok, I guess I should try a different solution, thanks.

0 Karma
Get Updates on the Splunk Community!

Introducing the 2024 SplunkTrust!

Hello, Splunk Community! We are beyond thrilled to announce our newest group of SplunkTrust members!  The ...

Introducing the 2024 Splunk MVPs!

We are excited to announce the 2024 cohort of the Splunk MVP program. Splunk MVPs are passionate members of ...

Splunk Custom Visualizations App End of Life

The Splunk Custom Visualizations apps End of Life for SimpleXML will reach end of support on Dec 21, 2024, ...