Multi-tenancy issue in RoR (again)

1

Hi,

I’m experiencing some weird behavior with Kibana RoR plugin when using multiple .kibana indices. It looks like they’re somehow mixed in between and sometimes I loose default index-pattern.

Let say I have a user A and a user B with each a different .kibana index (.kibana (default) and .Bkibana to make it simple). Both users have different rights on indices in the cluster, let say user A has access on indices_for_A_* and user B indices_for_B_*.

We now create index-patterns for A the following way:

  • indices_for_A_201901*
  • indices_for_A_201902*
  • indices_for_A_201903*
  • indices_for_A_201904*
  • indices_for_A_201905*

same for user B but with indices_for_B, well you got the point.

Now I log in with user A, go to discover and everything is wonderful I see all the defined index-patterns which were created before. I open a new window, log in with user B and everything is still wonderful, I also can see the index-patterns defined for B.

The trick is now I refresh the page where I logged in with user A and I suddenly end up seeing all the index-patterns defined for user B, why?

Thanks in advance for your help and should you need any clarification on the problem, please tell me

2

The experiment should be conducted with two independent browsers, otherwise it’s normal that if you log in with A in one window, then B in another window, and refresh the A window and the identity has changed.

When you login, ROR writes the identity object in a cookie. The cookies are a shared storage between windows of the same browser.

3

Sorry, I should have precised that the thing occurs in different browsers for sure (sounded obvious to me)

4

@zonArt what version of ROR and Kibana is this?

5

ES/Kibana: 6.5.3
RoR: 1.18.1

To precise a little bit when I got the index-patterns override it’s between a user with default (not explicitly defined) .kibana and another one with a specific one

6

Reproduced, thank you. Will work on this tomorrow.

7

FIXED, tricky bug :slight_smile:
Will PM with a pre build, so you can validate. Ok?

8

Sure,

Thank you, waiting on it

9

Hi @zonArt, Thanks for validating the fix!
I just would like to remark great part of the reason it was possible to come up with a fix it this quickly was thanks to the well described “reproducer” test case you laid out for us. So thanks for that too :slight_smile:

PS: The fix will be publicly released in 1.18.2

1 Like
10

Hi,

Sorry to re-open this painful case, but it looks like the fix is unfortunately not solving the problem. We’re still experiencing issues with lost default index-pattern which is really painful (especially since we use it in production). I also noticed mixed object between different contexts (don’t know if it happened with index-patterns as initially mentioned but exportable objects which were retrieved from another context).
Another bad news is that this behavior is random, I can try to dig in the logs and provide them to you once issue is occurring but I won’t be able to give a step by step stage to reproduce the issue.

11

Hey @zonArt, are you still using the 1.18.2 for 6.5.3?

12

yes we still do use the pre-built of 1.18.2 for 6.5.3

13

I managed to reproduce this. Steps:

  • Kibana 6.5.3, ROR 1.18.2 enterprise installed.
  • Two users, one has a “kibana_access” rule specified, the other not (should fallback to default kibana index, typically .kibana)
...
   - name: "::ADMIN_GRP::"
      groups: ["ROR (admin)"]
      kibana_access: admin

    - name: "::Infosec::"
      groups: ["Infosec"]
      kibana_access: admin
      kibana_index: ".kibana_infosec"
  • Delete all indices from ES, except one called “readonlyrest-xyz”
  • Restart Kibana afresh
  • Have Chrome browser on the left, login as the first user (group ROR (admin))
  • Have Firefox browser on the right, login as Infosec (the one with a custom kibana_index)
  • With Firefox, navigate to Discover, create an index pattern called “readonlyrest*”
  • With Chrome, navigate to Discover and see the index pattern created in the point above. It should not be there!

Workaround

The issue can’t be reproduced if we explicitly specify a “kibana_index” for all the users. For example:

...
   - name: "::ADMIN_GRP::"
      groups: ["ROR (admin)"]
      kibana_access: admin
      kibana_index: ".kibana_admin" # <-- added this line

    - name: "::Infosec::"
      groups: ["Infosec"]
      kibana_access: admin
      kibana_index: ".kibana_infosec"

Will behave ok.

We are currently working on the actual fix. Thanks for the patience!

14

Hi,

Thanks for the tip, was also looking in this direction. Explicitly giving kibana_index for everyone seems a very good idea. I however have a question, is it possible to define (still explicitly) the default .kibana index or do you really need to chose another one to avoid the issue?

Thanks again for your help.