When I create a role and assign it to a user in Splunk Enterprise, I have successfully tested that the user can only see events/data from the indexes specifically selected for that role.
However, when logged in as that user, in Splunk Enterprise Security, when accessing the "Security Posture" dashboard, for example, it appears the role restrictions given in Splunk Enterprise do not carry over to enterprise security. On the Security Posture dashboard, the user I want to limit access of data to can see everything. This is because there are no restrictions in place on the "es_notable_events" source in ES, for example. I would like to put a restriction in place so the logged in user can only see notable events from the indexes the user is restricted to in Splunk Enterprise, hence the only data the user can see in the specifically selected indexes, and nothing more.
A restricted user and a Splunk admin has the same visibility to all data on the Security Posture dashboard (and all other applicable dashboards and displays as well).
Is there a way to limit visibility in Enterprise Security (notable events and such) to only data from the indexes the restricted user has access to in Splunk Enterprise? It seems that the role restrictions put in place in Splunk Enterprise do not carry over easily to Enterprise Security.
I can create a bunch of customized dashboards and reports with queries filtering on hostname and/or IP range only, but this is a lot of work for something where an option may just need to be set, or an extra parameter added to the role somewhere.
Maybe Splunk can make this more easy to manage in a future release of Enterprise Security?
I was expecting this response. I did not find an easy way to get this done. I have posted the idea to the ideas website.
Hi @ at all,
I encountered this problema in a proposal and Splunk Professional Services asked to me an order to make this configuration!
Ciao.
Giuseppe
ES gets its data from the notables index so access restrictions on other indexes don't apply. I think you've already found the best solution/workaround, but consider suggesting a change at https://ideas.splunk.com