Security Best Practices and the default Search & Reporting App

[kwkkarl]

Noob here.

I thought I read somewhere that you should not give users access to the default Search and Reporting App. This should be for Admins only.

Instead, you should create a custom app and secure their access by roles and or indexes with the custom app.
Is this correct, And if so, is this documented anywhere?

I mentioned this to a consultant and was told that he was not familiar with this. So I’m wondering if I misunderstood what I read.
And unfortunately I have been not been to find the original document that started me down this path.

Thanks in advance for your replies.

[sloshburch]

This probably came from me. I talk a lot about the concept of using apps as Workspaces. The premise is that as the user base of Splunk grows, you would do well to give each group their own app, or Workspace, to work in. This makes the S&R not so cluttered, promotes collaboration with the intimate environment, and constrains the impact of knowledge objects to those working in the workspace.

See Workspace best practices for a Splunk deployment for more information and a link to the Welcome Page Creator for Splunk on Splunkbase which comes with a barebones workspace template.

[woodcock]

I wouldn't go so far as to disallow access to S&R but I totally agree that every group of users should have their own creative app where they should do all of their work so that it can be managed separately.

[richgalloway]

I heard of sites blocking access to the S&R app, but nothing says you should do it.

S&R is blocked to prevent the real-time search that runs to populate the "What to Search" panel. In a system with a lot of users, all those real-time searches can tie up a lot of resources. A custom app is usually used as the default app to replace S&R.