Best practice to restrict access to view events by sourcetype?

[myandow]

Is there a best practice to restrict access to events in Splunk by index and sourcetype?

I have tested using the "Restrict search terms" setting, but have found that there are far too many unintended side-effects that make this an undesirable option. As far as I can tell the best option is to use the forwarder to split up sourcetypes by index, and then assign the access to each index via roles.

Am I missing any other options? What do other people do to provide this functionality?

[rjthibod · Accepted solution]

To answer your primary question, indexes are the only guaranteed way to restrict access per role or user.

Now, how you separate sources/sourcetypes in indexes depends on how your deployment is configured. There is no prescribed way to do this, because the actual implementation of the separation is tangential to how splunk enforces RBAC at the index level. So, you can separate the data at the Universal Forwarder, Heavy Forwarder, or Indexer.

Just an FYI, note that any saved searches that run against the data need to take into consideration the RBAC you have setup at the index level. You need to make sure you don't transgress the RBAC limits with a saved search that writes data to a summary index that is visible to users that shouldn't see the data.

Also note that Datamodel acceleration does follow RBAC rules you setup at the index-level.

[sloshburch]

Yea, you guys nailed it. RBAC with indexes are really the best approach. A great build on this is to use naming conventions that allow you to use wildcards in the role definition of indexes allowed. Lemme know if that isn't clear.

[rjthibod]

The wildcard approach is exactly what I use my app. Works great for me and our unique data source.