Dashboards & Visualizations

What's the best way to limit a role so it only has access to a dashboard? It has a lot of drilldowns.

pamcarvalho
Path Finder

Hey guys!

So, I created this Dashboard, but the people that are going to use it shouldn't have any access to data/logs, other Splunk Apps, or anything Splunk related. Which means, they should access the Dashboard only.
I thought about embeding reports, but since the Dashboard depends on an initial input and it is dynamic (the are a lot of drilldowns), probably wouldn't be a good idea.
So l thought about creating a user role to have access to that Dashboard only, or create an App and configure the role to access only that App, and nothing more. But I am not sure if that is possible, considering I don't want the role to have access to other things such as App, "Search & Reporting", logs, etc.
Can anyone help me with this please?
Thanks in advance!

Pâmela Carvalho

0 Karma
1 Solution

niketn
Legend

@pamcarvalho, security/restrictions of dashboard can be applied at so many levels, depending on how much strict it has to be:

1) Create a Read Only Dashboard by converting from <form> to <dashboard>:
Create a Read Only copy of your existing dashboards with all the Initial Inputs defaulted to hard coded values. Users with Read Only access can access only these dashboards hence will not have access to change the Input values like Time, Dropdown etc. Documentation on Access (https://docs.splunk.com/Documentation/Splunk/latest/Viz/DashboardPermissions)
Remove <drilldown>/<selection> code from Read Only Dashboards if they are not required.

2) Hide Splunk Default Header, Footer, Splunk Bar and App Bar
Set <dashboard> root node attributes for hideChrome, hideSplunkBar, hideAppBar, hideEdit, hideFooter etc. to get the default links removed. PS: You may need to create one Dashboard with your own navigation menu (if you wish to hide App Bar), or a pre-built panel/s to create your own header for Navigation and/or Footer (if you wish to hide Splunk Footer) for information.

http://docs.splunk.com/Documentation/Splunk/latest/Viz/PanelreferenceforSimplifiedXML#dashboard_or_f...

3) Customize App Navigation (Splunk App Bar)
If you want to remove Reports, Search, Alert from Splunk App Navigation, you can edit the same. Refer to Splunk Dev Site: http://dev.splunk.com/view/webframework-developapps/SP-CAAAEP9

4) Disable Search/Export/Inspect/Refresh links on Panel hover
Simple XML Chart options like link.openSearch.visible etc can be used to disable drilldown from Search Panels. This options are available as Panel Footer when we perform mouse hover.Refer to documentation: http://docs.splunk.com/Documentation/Splunk/latest/Viz/PanelreferenceforSimplifiedXML#dashboard_or_f...

5) Control Events/Access/Visibility on Dashboard based on Role:
This will give you more robust an specific control over your dashboard based on logged in user role. You can use Splunk REST API based search to get logged in User's Role and based on the same you can wire in your JavaScript to enforce the authorization you intend to implement. Refer to my answer on one such use case: https://answers.splunk.com/answers/575377/can-i-restrict-permissions-for-the-text-box-drilld.html

Please let us know if you need further details on any of the above approaches or if you are looking for something beyond these.

____________________________________________
| makeresults | eval message= "Happy Splunking!!!"

View solution in original post

niketn
Legend

@pamcarvalho, security/restrictions of dashboard can be applied at so many levels, depending on how much strict it has to be:

1) Create a Read Only Dashboard by converting from <form> to <dashboard>:
Create a Read Only copy of your existing dashboards with all the Initial Inputs defaulted to hard coded values. Users with Read Only access can access only these dashboards hence will not have access to change the Input values like Time, Dropdown etc. Documentation on Access (https://docs.splunk.com/Documentation/Splunk/latest/Viz/DashboardPermissions)
Remove <drilldown>/<selection> code from Read Only Dashboards if they are not required.

2) Hide Splunk Default Header, Footer, Splunk Bar and App Bar
Set <dashboard> root node attributes for hideChrome, hideSplunkBar, hideAppBar, hideEdit, hideFooter etc. to get the default links removed. PS: You may need to create one Dashboard with your own navigation menu (if you wish to hide App Bar), or a pre-built panel/s to create your own header for Navigation and/or Footer (if you wish to hide Splunk Footer) for information.

http://docs.splunk.com/Documentation/Splunk/latest/Viz/PanelreferenceforSimplifiedXML#dashboard_or_f...

3) Customize App Navigation (Splunk App Bar)
If you want to remove Reports, Search, Alert from Splunk App Navigation, you can edit the same. Refer to Splunk Dev Site: http://dev.splunk.com/view/webframework-developapps/SP-CAAAEP9

4) Disable Search/Export/Inspect/Refresh links on Panel hover
Simple XML Chart options like link.openSearch.visible etc can be used to disable drilldown from Search Panels. This options are available as Panel Footer when we perform mouse hover.Refer to documentation: http://docs.splunk.com/Documentation/Splunk/latest/Viz/PanelreferenceforSimplifiedXML#dashboard_or_f...

5) Control Events/Access/Visibility on Dashboard based on Role:
This will give you more robust an specific control over your dashboard based on logged in user role. You can use Splunk REST API based search to get logged in User's Role and based on the same you can wire in your JavaScript to enforce the authorization you intend to implement. Refer to my answer on one such use case: https://answers.splunk.com/answers/575377/can-i-restrict-permissions-for-the-text-box-drilld.html

Please let us know if you need further details on any of the above approaches or if you are looking for something beyond these.

____________________________________________
| makeresults | eval message= "Happy Splunking!!!"

pamcarvalho
Path Finder

Just one question, I already have everything hidden: Splunk Bar and App Bar, so the user can only see the dashboard, but still, if the link to access the dashboard is "$SPLUNK_HOME/app/search/DashboardName", the user can manipulate the link to "$SPLUNK_HOME/app/search/", and then they would have access to Search and our log/data, which is what I am trying to avoid. Any idea how to solve this?

0 Karma

niketn
Legend

You will have to introduce Role based restrictions. However, you can not take away user's access to search the data based on which Dashboard is created or else even Dashboard will stop working.

I am sorry but I cant think of a way restriction can be enforced on manually typed URLs like <URL>/app/search/search

____________________________________________
| makeresults | eval message= "Happy Splunking!!!"
0 Karma

pamcarvalho
Path Finder

I see, thats fine, don't worry, you already helped a lot, thanks!
But do you know how to exclude option "Search" from the App Bar?

0 Karma

niketn
Legend

If you intend to use Splunk App Navigation, the same is mentioned in Step 3 above. You can customize navigation from Settings > User Interface > Navigation > default.xml. Details to customize navigation is listed in the dev URL (http://dev.splunk.com/view/webframework-developapps/SP-CAAAEP9).

____________________________________________
| makeresults | eval message= "Happy Splunking!!!"
0 Karma

pamcarvalho
Path Finder

True, sorry! Thank you very much for your help once again!

0 Karma

pamcarvalho
Path Finder

That's exaclty what I needed!!!! Thank you very much @niketnilay!!!

0 Karma
Get Updates on the Splunk Community!

Enterprise Security Content Update (ESCU) | New Releases

In December, the Splunk Threat Research Team had 1 release of new security content via the Enterprise Security ...

Why am I not seeing the finding in Splunk Enterprise Security Analyst Queue?

(This is the first of a series of 2 blogs). Splunk Enterprise Security is a fantastic tool that offers robust ...

Index This | What are the 12 Days of Splunk-mas?

December 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...