Kibana plugin enhancement

:bulb: Kibana plugin hiding indices

At the moment we can specify the indices that users have access to, but the list of all indices is still visible to users, they can click on the index and will get authorization error. I would like to have the option that kibana would hide the index that user do not have access to in the list they have in their account - something similar to kibana hiding application tabs for users.

:rocket: Let’s do this?

  • 1
  • 2
  • 3
  • 4
  • 5

0 voters

OK this looks important. Hey @nan008 can you take a short video with your mobile and show me this UX inconsistency? This forum doesn’t really support uploading a video as a comment, so maybe via Twitter @s_scarduzio

Ok, let see if I can explain with pictures first - if not I will record the video

So Group DEV has ro to kibana with access ONLY to anna02

So when you are login to Kibana getting this screen

with the list of indices:

I should not have access to anna03 according to the yml

but you can still click on it, you will get the error below:

My point is that I want the list of indices to reflect only the indices that I have access to, in my case only anna02 (we have at the moment 236 indices and 3 groups that have access to ES, 1 group has only access to 2 indices but have to go through the whole 236 to find the indices that they have access to)

Hope this is clarifying my New Feature Idea - idea

1 Like

Hey @nan008, I checked that dropdown. It takes the list from the “index patterns” setting of Kibana. This means that it lives in the same domain with all the dashboards. We’d need to implement full multitenancy to support different users with their own dashboards and Kibana settings.
This is a beefy one, and needs some investigation to see what’s the best way to implement it. How would you enjoy having this feature from 1 to 10?

I would like it that is for sure, so 8 - we found a workaround for now and display only aliases now for users with two - three indies in one alias using curator to delete the indexes that are not necessary.

I would like to see it in the future as our index base will grow - even aliases will at some point make a large list. If we can hide the data that the user do not have access to, it will be awesome. I am not saying that it is urgent and need to come with the next release but if at some point we will get it, that would be great.

1 Like

@nan008 try using kibana own home plugin … It works with readonlyrest and does the above mentioned job :slight_smile:

@shubhamverma27 not really following - can you be more specific what kibana home plugin? We are using the ROR and ROR_KBN for the security and it doesn’t hide the list. Are you talking about x-pack?

No Its a Seperate Plugin…
Check this :-

Will this work with ROR and ROR_KBN security? Did you tested both readonlyrest and readonlyrest_kibana with this plugin? I requested it as new feature as we would like to have as little plugins as possible in our EKL environment. Thnks for this suggestion I will look into it. @sscarduzio would not this be a possibility of assigning kibana.index to every group to allow indices visibility and individual dashboards for each group according to the yml instead of rearranging the settings?

Yes, I did…
But I am Currently not using it as I was not able to connect it to LDAP to make Groups .

@sscarduzio also has a method but I dont think its implemented yet :thinking:
check this out

@shubhamverma27 are you referring to kibana_index rule?

Unfortunately, at the moment, it’s still required to run multiple instances of Kibana in conjunction with this rule. See the description from the docs:

OPTIONAL: (Defaults to .kibana) specify to what index we expect Kibana to attempt to read/write its settings (use this together with kibana.index setting in kibana.yml.)

@nan008 I made SOME progress, I managed to “fool” the Kibana backend into changing kibana.index according to the login. Now the problem is to fool the front-end. Will keep you posted.

@sscarduzio hmm… @ld57 told me that …
I guess now what could be easiest method is to implement own_home with readonly :thinking:
While in built multi tenancy in readonly would be great

I never used own home, I know CERN uses it, but with a good deal of proxy & automation glue.

This is covered by the multi-tenancy feature offered currently in ReadonlyREST Enterprise