Allow "locking" of dashboards/visualization/searches

[Vineeth-Mohan]

After creating a dashboard , i want to publish a dashboard link which don't have an configuration options but just the dashboard , its visualization and ability to do queries. This would be greatly useful to make dashboard and provide the link to end user who wants only to use and query the existing visualizations but dont want to edit them or add new visualization.

[rashidkpc]

Thanks, this is something we have planned for the future, though haven't had a chance to figure out where it fits on the roadmap just yet.

[sqpdln]

Could it be possible to have a Shield-config to provide a read-only-state on the .kibana-index for some users? I tried with different subsets of the default kibana4 shield config, but haven't succeeded.

[w33ble]

Also related to this are #3046 and #2503

[cedosw]

Still looking forward to this. I really put a lot of work into my dashboards, so I obviously want to share them with other people but dont want anything to be changeable. Is this already in work or are there any workarounds maybe? Would appreciate some help.

[radiumx3]

👍 Looking for this as well

[xavierromero]

I'm also very interested on this. I would add an "extra" feature: ability to share a FILTERED dashboard so that the end user can't edit/see the filter.
Right now I can share the filtered dashboard but the user can see and remove the filter.

Best regards,
Xavier Romero.

[crudbug]

@xavierromero You are right on the money.

"Sharing the State of a Dashboard/Visualization" is the most generic solution.

[peterhawkins]

Looking for this also. May have to resort to a custom proxy to strip out the header... You definitely have 2 distinct classes of user, dashboard designers and chart ooglers.

[immunochomik]

I do need that +1

[srijiths]

This would be a useful feature +1

[lhorsky]

This is definitely needed!

[random1223]

+1

[cburkins]

Anxious to use Kibana with a large group, but worried about having to maintain the dashboard. Would love a way to create a read-only dashboard/link

[ni-ka]

+1 same requirement for our project

[andreoid]

+1 here too. I want to share my dashboards with a non-technical audience!

[yehosef]

+1

[JAGAxIMO]

+1

[shadowcodex]

+1

[ssoto]

👍 here. It is annoying when clic and charts move and resize. Nice job!

[aldanor]

+1!

[sayakb]

+1

[Tomato-]

+10086

[giri786]

+1

[awashbrook]

+1 Read-only dashboards are a key feature of my bespoke angular dashboard solution right now, we are are looking to migrate to Elastic 5, this will be a blocker for us.

[cjfpainter]

+1

[godson2006]

run this curl command to lock kibana (Dashboards, visualizations, discovery, soup to nuts)
curl -i -X PUT http://$ELASTIC_HOSTNAME:9200/.kibana/_settings -d "cat /app/platform/elasticsearch/index/lockKibanaIndex.json"

lockKibanaIndex.json
{ "index":{ "blocks":{"read_only":true}}}

Tested with Kibana 4.6.0, will not work with Kibana 5.1.1 which i just found out :). Shield is buggy in my opinion, although I last used it with Kibana 4+

[tullydwyer]

+1

[obudiman]

+1

[korczis]

Is there any plan to implement this feature?

[stacey-gammon]

This is definitely on our radar. As a first step we are working on implementing View and Edit modes. Once that is complete we are going to further investigate these use cases and possible solutions.

[kokojumbo]

+1
Are there any workarounds with usage of nginx proxy for kibana 5?

[olivierlambert]

@kokojumbo IIRC, you can use a dedicated URL that filter all POST request, therefore it will be in read only. Use another URL with a passwd (for example) with all request allowed for R/W.

[kokojumbo]

Filtering POST requests doesn't help. Then it blocks POST requests to /elasticsearch which are necessary to show visualizations.

[kokojumbo]

I found a workaround using nginx. It blocks savings and edits, but still public users can access the kibana panel. This solution provides read-only proxy.

Nginx configuration proxy
Blocking POST requests to elasticsearch except search and get (kibana uses POST request in js to show charts)

server {

    listen 80;
    server_name localhost;

        location ~ (/elasticsearch/.kibana/index-pattern/_search|/elasticsearch/_mget|/elasticsearch/.kibana/_mapping|/elasticsearch/_msearch)  {
		proxy_pass http://kibana:5601;
		proxy_http_version 1.1;
		proxy_set_header Upgrade $http_upgrade;
		proxy_set_header Connection "upgrade";
		proxy_set_header Host $host;
		rewrite /(.*)$ /$1 break;
	}
	location ~ (/elasticsearch/)  {
		return 405;
    	}
	location ~ (|/app/kibana|/bundles/|/status|/plugins|)  {
		if ( $request_method !~ ^(GET)$ ) {
			return 405;
		}
		proxy_pass http://kibana:5601;
		proxy_http_version 1.1;
		proxy_set_header Upgrade $http_upgrade;
		proxy_set_header Connection "upgrade";
		proxy_set_header Host $host;
		rewrite /(.*)$ /$1 break;
	}
}

Nevertheless, I hope you provide this feature in the near future.

[olivierlambert]

Thanks for the workaround @kokojumbo !

[DPPWurd]

Nice solution by @kokojumbo, thought I did end up putting in a few more allowed routes to get everything in Dashboard working. Would really like to see this feature properly implemented, additionally with security options around which users would be allowed to see which report etc.

[doprdele]

Is this supposed to be in 6.0?

[stacey-gammon]

We've introduced "Dashboard only mode" in 6.0, available in x-pack (it relies on security features). You can read more about it here. You can also play around with it in the 6.0.0-beta1 preview release. Note however that those docs will be changing very shortly, as will the set up portion, in 6.0.0-beta2.

x-pack security already comes with the ability to set up read only users, this new feature just improves the UI that certain users with limited credentials see.

We also want to improve embedded options, such as allowing the search bar to appear in embed mode, so if your goal is to hide all of the chrome, but expose some additional features that aren't available in embed mode today, that will hopefully help.

[doprdele]

@stacey-gammon However, the kibana_user role right now in X-Pack is allowed to delete all the index mappings and the kibana.* index, will that fix this? Users aren't able to perform searches without at least the kibana_user role

[stacey-gammon]

You shouldn't need the kibana_user role to perform searches. If you want to set up a read only user, you just need to create a new role and give it permissions on your .kibana index, along with the privileges read and view_index_metadata. Something like this:

Then assign that to your user, and they will be able to log in to Kibana and perform searches. You should also give your user access to the data indices as well, or nothing will turn up.

Let me know if that helps.

[ThomasFlanaghan]

The link you posted for the details of the dashboard only mode no longer exists. Is this still coming in 6.0? I saw it mentioned in the keeping up with kibana blog posts a couple of months ago.

[stacey-gammon]

yep @ThomasFlanaghan, we just changed the implementation and docs a bit in 6.0-beta2. The new docs are here: https://www.elastic.co/guide/en/kibana/6.0/xpack-dashboard-only-mode.html

Let me know if you have any questions or run into any issues.

[danieljsc]

+1
Think it would be great having a share link/token where end-user could only see the dashboard without having access to another kibana areas/configuration. embed=true is a nice workaround in the URL, but is not secure as anyone who inspects the code can remove it.

[Idanatcox]

Hi @kokojumbo I've tried to set up the workaround you proposed on Kibana 5.5.1 and Kibana is trying to do a POST request to es_admin/.kibana/index-pattern/_search?stored_fields= which returns 405 (Not Allowed)
Any idea what could be the cause?
what version of Kibana your workaround works no?
Thanks!

[JohannesHartmanTR]

In cases where you have many regional ES-clusters where each is multi-tenant in nature, it would be cumbersome to grant roles to users. The option of having Kibana add a last_modified_timestamp property to any saved UI objects (visualizations, dashboards, searches etc.) that could be inspected to determine whether any changes were performed (and if so, reload them from the source repo) seems like a fairly low-effort implementation effort that could be used to control any configuration drift without the user-management overhead.

Would it be possible to add such a property (last_modifed_timestamp)? [Amendment: like in #9377]

[TheExploringDev]

+1.

Also, maybe a better Dashboard UI with lesser empty spaces would do wonders :)

[stacey-gammon]

Closing in favor of #18473. This will be handled in one form or another with granular RBAC to all saved objects.