Kibana Anonymous access - how do you prevent listing all dashboards?

We are using Elastic cloud, and have setup Kibana for Anonymous access so that users can share dashboard links publicly. The anonymous role is configured to only allow Kibana -> Dashboard Read permissions.
Screen Shot 2022-02-03 at 9.22.49 AM

This setup is functional but any anonymous viewer can now navigate to other spaces and list Dashboards.
Screen Shot 2022-02-03 at 9.27.59 AM

Is there a way to prevent Dashboard listing / space change for these anonymous users? Ideal would be a permission to only "View" shared dashboards but not list them. It seems the Embed option can generate URLs that hide Top menu and Query options - but that's easily circumventable to get access to all the dashboards.

It looks like you set up your anonymous user role to have access to * All spaces, which you probably don't want to do. If your anonymous users only have access to a single space, they won't be able to navigate to other spaces.

No, there's not a way to do exactly what you're asking. If a user has access to the Dashboard feature in a space, that allows them to access any dashboards in that space (and, by extension, view the list of dashboards).

There's nothing special about the "Share public URL" button that affects the particular dashboard you're viewing, it simply tacks on the anonymous user info to the URL so the user isn't prompted to log in when they view it.

A workaround would be to create a special "Anonymous" space, then copy all dashboards that you want to share publicly to that space, and change your anonymous user role to only grant access to that space.

@jportner thanks. Yes - the anonymous user is designed to have access to all spaces, but that's by design so any user in any space can share a public URL to a dashboard.

For additional context, we have created different spaces, one for each of our "customers" where they can create their own dashboards. What we are trying to accomplish here is to let them share public URLs to a specific dashboard that they create without giving access to all of them. So the special, "Anonymous" space workaround wont work here.

It seems this is not possible today but would be great if you could take this as a feature request - seems like it would be a fairly common use case for people to share public view access to specific dashboards but not allow listing all dashboards / spaces within a Kibana instance.

Here's something we tried but didn't get the desired results, BTW -
We put our elastic instance behind a cloudflare worker proxy, so that it can now be accessed via dashboard.mysite.com. This works wonderfully well.
Extending this, we tried to add an embed=true parameter to the URL whenever we see a auth_provider_hint param in there - hoping that this would get Kibana to not show the nav bar (like with embed links). Somehow though, this doesnt seem to work. Not sure if you have any ideas here..

Sure thing, I added an enhancement request here: Minimal access to prevent enumerating objects · Issue #125015 · elastic/kibana · GitHub

For what it's worth, Kibana is just not built this way and I don't think this is something we can realistically address anytime soon =/

I'm not sure about this, it's a bit out of my wheelhouse. I'll ping my colleagues who are responsible for this part of the code and see if they can help!

It looks like the embed=true parameter is working as intended -- but if you first open a dashboard and then add the parameter to the URL, you need to do a full page refresh for it to render properly.

Were you testing it by manually adding the parameter like that? If so, try to refresh the page and make sure it works as intended. It should also work if your reverse proxy is adding the parameter.

Before adding the parameter:

After adding the parameter, with a fresh page load:

If that's not working as described, please feel free to open a bug report on our GitHub repo.

It's worth noting that this won't really prevent the anonymous user from enumerating other dashboards if they are determined. But maybe this is "good enough" for your use case.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.