Is it possible limit user access to an index on a Search Head level?

[mathiask]

Use case: A customer runs his personal Search Head but we only want to give him access to certain indexes

Since we have no control over the SH, we cannot simply enforce the access on Role basis. It has to happen on the SH to Indexer Cluster level.

But I cannot see any restriction possibilities. When the SH connects to the Indexer Cluster, it authenticates with the cluster key and receives full cluster access to all indexes.

[mathiask]

Just for clarification and summary

Use Case

• Shared Splunk Indexer Cluster Infrastructure
• Certain user groups get their own SH, they can do whatever they want with it, they own it, i.e. full system root access, they are Splunk Admin on that box, they can change any settings they want. Therefore local role and app restrictions will not do anything.

Answer
The splunk architecture is not designed for this.
Access control and enforcement is done in the GUI and CLI on the SH. Therefore

• Anybody with Admin permissions on the SH can access and change permissions to all the data which the SH is connected to, because the SH has to connect with Splunk Admin credentials to the Search Peer. This is true for any kind of Search Head, whether in a cluster or not. The Indexer cannot/does not enforce access to indexes.
• Anybody with System root permission on the SH is able to get these permissions, somehow

Follow up Question
Is this also true when the SH connects not to a Indexer Cluster but as a normal Distributed Search Peer using credentials with the Splunk Admin role, but limited index access. E.g. splunk-adm-restricted has the admin role, but only access to the index main

Possible "Solutions"
The currently viable solution is to run independent infrastructures for each special user group.
Directly send the corresponding events to the infrastructures. This allows the special user groups to access the data "locally" while some other users that are hooked up to all the infrastructures can access all the events.
But this also creates some problems

• administration nightmare
• forwarder administration nightmare
• forwarder configuration nightmare, i.e. send system log to central and application to local infrastructure

OR you have a central infrastructure where all the data is being sent to. And then forward the select data to the infrastructure of the special user groups.
Still a total nightmare regarding infrastructure management, but the forwarder management is much easier. But you store the data more than once (except if you don't store it on the central one).

The other option is to only give these user groups limited GUI/CLI access without Splunk admin permissions and no System root access.
This limits somewhat the usage andr advanced features and configurations, but in general might be good enough.

[koshyk]

is the SH in a cluster?
if NOT create an app with new role for the user with fewer index access

[esix_splunk · Accepted solution]

So what you are describing is Distributed Search. And Splunk doesn't have the ability to limit access to distributed search heads by indexers. Your user configuration for distributed search is intrinsically all indexes, and then you have to limit access at the search head level via Roles and Capabilities.

[mikaelbje]

Someone please file a feature request. I see many situations where this is needed, i.e. outsourcing forensics/detection/SoCaaS while having your own infrastructute but where your partner supplies its own SH connected to other detection systems/engines

[aaraneta_splunk]

To file a feature request, it is recommended that you create a support ticket: http://www.splunk.com/r/bugs
You can choose the "All enhancement requests" under "Splunk installation is" section.

[mrgibbon]

Sounds like there has been a miscommunication when designing the system.
Is the Splunk system multi-tennant?
Looks like you are better off putting the data he requires in another index on a separate indexer machine.
If you don't have access to that search head, I don't know what you can do to restrict it otherwise.