In my previous post Saved Search Permission Model Changes in Splunk 6 I discussed a change in Splunk’s permission model for Splunk 6. While there are security considerations, if you have upgraded you have already assumed that risk, so you might as well utilize the benefits.
One example is our networking team has some use cases where an end-user calls the help desk having a networking issue; they networking team would like the help desk to be able to search the logs and if there is an obvious issue with a known correction, then the help desk could go ahead and resolve the issue for the user. Luckily, we also have some fairly advanced users in that group which should help assure this goes smoothly.
First, have the networking team identify the saved searches they want to share and work with them to adjust the permissions so that only their team and the help desk can see those queries — we have about 50 different internal groups utilizing Splunk and we don’t want all users to have access to these saved searches.
Second, while we could then have the help desk either directly invoke these queries with
|savedsearch or create the dashboards so they are structure how they want, our help desk has limited Splunk experience while our networking team has really taken the plunge, so we’ll create a new app where the help desk has read access and the networking team has both read and write access.
Third, we’ll have the networking team develop the dashboards they feel would be helpful ensuring they utilize saved searches and then communicate those dashboards to the help desk. We give all of our users a writable app so they have an area that’s theirs, so some of this will be moving dashboards over; we can easily cheat and to a cp on the command line to speed up the copying process.
Then, through this new Saved Search Permission Model, when the help desk views the dashboard, they will be able to see the data.
The primary impact of the above scenerio could also be solved by partition the data at a more granular level and granting the help desk access to just what they need if the dashboard is showing raw data or fields from raw data.
If the data is summarizing things, summary indexing could also be used.
While I highlighted this concern in my previous post, it bears repeating: now that a saved search could be granting new access, I have concerns that an SPL Injection class of vulnerability exists where filtering forms fields are exploited to gain unintended access. This would be in addition to the configuration errors where saved searches are now granting unintentional access to data.
Since Splunk 6 has expanded the capabilities of simple xml, its fairly easy to make dashboards with time pickers, filtering forms, and even that execute one search and then post process it for different perspectives.
In response to Splunk’s confirmation of this as an intended feature, we replied with an inquiry into other situations outside of dashboards where they think this could be useful, but for us this new dashboard capability is an amazing and unexpected step forward.