Kibana: 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]

:+1: 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!

[exsun]

+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]

:+1: here. It is annoying when clic and charts move and resize. Nice job!

[aldanor]

+1!

[sayakb]

+1

[Tomato-]

+10086

[bdunbar]

+1. And a emojii thumbs up in the bargain.

[novozhenets]

+1

[mpok3]

+1

[emilevauge]

+1

[jomar83]

+1

[rkovalyov]

+1

[goacid]

+1

[narutaro]

+1

[Ardoise]

+1

[Ralnoc]

I would say this is a critical component for making Kibana fully ready for active use. The ability to restrict who can create or modify visualizations and Dashboards. This is especially true when you can impair a cluster by a badly designed visualization

[JPriya2]

+1

[pmoust]

:+1:

[sujuhu]

+1

[diclophis]

+1

[diclophis]

Also, as a workaround for trusted embedded applications

<style>
iframe { pointer-events: none; user-select: none; }
</style>

Also it occurs to be that the ability to set the layout from a url parameter would allow for easier per-user layout preferences...

[lijamez]

+1

[jnbala]

+1

[ctr0]

+1 !!

[felixbarny]

+1

[tcucchietti]

This is definitely needed for production use! +1

[amgokak]

+1

[tlau]

+1

[rauljim]

+1

[rodeli]

+1

[spawnrider]

+1

[filipkokorevs]

+1

[marfago]

+1

[jvaa]

+1

[umair9]

+1

[marcinkubica]

+1

Sent from Gmail Mobile

[calumah]

Without shield I tried to lock .kibana index on readonly mode :

curl -XPUT 'localhost:9200/.kibana/_settings' -d '{ "index.blocks.read_only" : true }'

It's working well, nobody can save/delete a dashboard / search / visualization. If user resize / move something on dashboard he can reset easily by bookmarking dashboard without parameters in url (or load it directly).

If admin need to edit something, I change temporally http password and set index.blocks.read_only to false, then revert. This is not perfect but it's secure I think.

[TheBig159]

I have the same problem and I'm experimenting following this criteria:
1) I've installed 2 Kibana instances working on 2 different ports: 5601 for users, 5699 for me (admin)
2) The user instance was set up/installed as explained in CONTRIBUTING.md file in the package that I cloned from Git. In this way I can make modification to the files "building" the interface and see the result immediatly on browser
3) I started to study the files in the various folders finding which one controls which element on the UI interface and doing the modifications that I need

The result is that I have the standard UI for me on port 5699 where I can do new searches, visualization, dashboard and modify what already I have created and the "limited" UI where the user can just look at what I propose him. I left the ability to modify the time range but with a day span max. Every modification I do on my side it is reflected in the user side after F5 or, sometimes, reopening the browser.

I'm still experimenting but it seems promising. What I'll have troubles to test it is performance but since I'll have many users and just one Admin the chance to overload the server will be small because, if I want I think that I could activate the Kibana for the Admin only when it will be needed.

When I'll be finished I'll have to repackage the altered Kibana and install it in production.

[ikaruce]

+1 I'm also waiting this feature.

[lavaalone]

+1 for production use

[udaysagar2177]

+1
Did anyone try the below solution?
https://gist.github.com/r0mdau/db31403c0338b057bc7a
and using two kibana instances, one by admin, for modifying the content and other one(which points to nginx server) can solve the problem, right?

[elvarb]

If you front kibana with a reverse proxy you can limit http methods with authentication. This way anyone can do get and post, but limit put and delete.

[marfago]

The solution should work, but you'll still continue to see sections as editable. Kibana will return an error when trying to save changes.

[elvarb]

Or the reverse proxy will prompt the user for authentication

[chintanKalkura]

+1 waiting for use in production

[GerySt]

+1 for read-only dashboards/visualization/searches

[maximgue]

+1

[oussemos]

+1 for this feature

[muradm]

+1

[alowde-catapult]

+1

[prabhakarmanthena]

+1

[pemontto]

:+1:

[bubebyte]

+1

[rlgomes]

:+1: any idea when/if this would land ?

[dmehra]

+1

[psaiz]

+1

[lakal-malimage]

+1

[jamrite]

+1

[mxr-mwaters]

+100

[ibobak]

+1

without this feature the project of self-service BI (which I am currently building) based on Kibana+Elasticsearch will most probably fail....

[rlgomes]

@ibobak you may want to checkout http://grafana.org/

[ibobak]

Just tried to make the connection from graphana to elastic and to build a dashboard. Got some weird things with js/html in graphana. Unstable.

Kibana is much better, but unfortunately, this feature is missing...

[souf989]

+1
Hi I am very intersted in this functionnality ! I face a lot of clients that need's to secure the access to specefic dashboards in read only mode

[dfaropennetwork]

++1

[mrgaryg]

+1

[guareber]

+1

[quatrix]

+1

[goldsteinalon88]

+1

[edmarriner]

+1

[unixsurfer]

+1

[gunererd]

+1

[thedarkdestructor]

+1

[mdhaseeb]

+1

[vtipparam]

+1

[danidano]

+1

[bwalsh]

+1

[pietervogelaar]

+1

[Idanatcox]

+1

[MarcoDeJong]

+1

[dfaropennetwork]

+1

[bimalpaul]

+1

[goindwalia]

+1

[olivierlambert]

+1

[mathesonphillip]

+1

[jlruizmlg]

+1

[nathan-cosmos]

+1

[dseravalli]

+1

[cah-oster]

+1

[sagh0900]

+100

[slowprog]

+1

[marcuslacerda]

+1

[imharshj]

+1
Does anyone have a successful workaround in the meantime?
Need to prevent end users from adding/modifying/deleting visualizations or dashboards.
Even shield doens't have this capability?!

Edit: Temp solution.

1. Used above mention trick to make dashboard read only.
   curl -XPUT 'localhost:9200/.kibana/_settings' -d '{ "index.blocks.read_only" : true }'
2. Edited the CSS for kibana to remove the (edit/remove) icons from the dashboard panels.

_Navigate to_
/opt/kibana/optimize/bundles/kibana.style.css
(row ~ 3170)

_Add a line to make this element hidden._
.gridster dashboard-panel .panel .panel-heading div.btn-group {
_visibility: hidden !important;_
white-space: nowrap;
-webkit-box-flex: 0;
-webkit-flex: 0 0 auto;
-ms-flex: 0 0 auto;
flex: 0 0 auto;

[sagh0900]

I configured two extra instances of kibana to run on different ports (ex: 5601, 5602) in separate host and made them to connect to elasticsearch cluster. Blocked the actual kibana URL usually we expose to customers. Configured both the kibana instances have their own .kibana index in their kibana.yml.

Configured apache on the host where two extra instances of kibana and running. Configured virtualhost based on CNAME and did proxy to different kibana instances which are running on different posts.

Blocked the "POST" urls which have op_type=create and disable the create button on two kibana instances which will be accessed through webserver. Did this blocking in virtualhost file. Also configured basic authentication which credentials are read from separate password file. for ex: http.passwd (you can use .htaccess as well)

But we(admins) will create indices for the user when they requested (we will SSH tunnel directly), hence only those indices are available for the users (respective credentials will be shared to users). Since each kibana is having different CNAME which is given to user, and the respected kibana instance have their own index, the work around seems OK for now.

But still +1 for this feature.

[barryhatfield]

+1

[MohMaz]

+1

[balooka]

+1
I will look into the workarounds mentioned here, but would definitely favor an integrated solution.
Is there any indication of when this feature could be made available?
Last update that even remotely relates to release planning is @rashidkpc adding the P3 label on January 2016.

[yuri1969]

+1

[Dom-nik]

+1

[wsmolarek]

+1

[dwerder]

+1

[Cylindric]

Is this likely ever to be implemented? Seems elastic.co would prefer we pay for Shield, at a seriously non-trivial cost. :(

[stacey-gammon]

For anyone interested in simply hiding the edit controls, you can append &embed=true to the dashboard url. Note that this is not a secure read-only mode however, as anyone could remove that parameter from the url to get back the edit controls.

[DotNetRockStar]

+1

[elvarb]

What @Stacey-Gammon posted and using a reverse proxy to limit update and delete methods is a good solution for now

[bittenApple]

+1

[xdzhou12]

+1

[diedirk]

+1

[ChaDup]

+1

[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!

[jjphartman]

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 https://github.com/elastic/kibana/issues/18473. This will be handled in one form or another with granular RBAC to all saved objects.