Is this a valid configuring for achieving Multi Tenancy?

1

Hello ROR Team,

Below is the use case we have.

We have customers for whom we manage log data. For each kind of log data they have different indices. The indices pattern is kind of controlled by our logstash configuration like below.

<CustomerName>_<CATEGORY>_<CustomerId>_*****

Now our aim to achieve the below tasks.

  1. When a user from Customer A with Viewer Permission, logins he should only see dashboards/visualization/indices/index patterns configured for that customer.

  2. When a user from Customer A with ReadWrite permission logins, he should be able to see dashboards/visualizations/indices/index patterns of that customer only and be able to define additional ones.

One way to achieve this in ROR, is to have RO/RW/Admin groups for each customer and define users for it. But this is not going to be manageable for us.

Below is what I tried and it seems to be working. But we want to make sure there are hidden gotchas that we should worry about.

- name: “::READONLY::”
  kibana_access: ro
  kibana_index: “.kibana-cfxdls-@{user}”
  verbosity: error
  jwt_auth:
    name: “jwt_provider_1”
    roles: [“viewer”]
  indices: [".kibana-cfxdls-@{user}", “ *@{user}* ”]
  kibana_hide_apps: [“readonlyrest_kbn”, “timelion”, “kibana:dev_tools”, “kibana:management”]

- name: “::READWRITE::”
  kibana_access: rw
  kibana_index: “.kibana-cfxdls-@{user}”
  verbosity: error
  jwt_auth:
    name: “jwt_provider_1”
    roles: [“writer”]
  indices: [".kibana-cfxdls-@{user}", “ *@{user}* ”]
  kibana_hide_apps: [“readonlyrest_kbn”, “timelion”, “kibana:dev_tools”]

- name: “::ADMIN::”
  kibana_access: admin
  kibana_index: “.kibana-cfxdls-@{user}”
  verbosity: error
  jwt_auth:
    name: “jwt_provider_1”
    roles: [“admin”]
  indices: [".kibana-cfxdls-@{user}", “ *@{user}* ”]

jwt:
 - name: jwt_provider_1
   signature_algo: HMAC
   signature_key: “wr8sFmw1jP9JpBjPGKJwvOJg4mIqAwMOaRZ7UrkhIgs_IqlORSEFVU3Go-Ozj9strEIb_NuLqdTCYz9IlZ-pa13S7lun7eyHwzHDKw8m-1LVq0hMUldT0JPLE7OQBY3hhnUk0gtfFW61x31frt7AMZuAPY9UbcaIbVfvwAb5xQgPlc1QkAA-uRfO2qUMPXRQcpIJSbWlqqZioFoAHUiJytRsg_QaWE1kmjHrkg1ueBZqaSXZyBQHnBepPvw8tX9dn-X1yTygiZZ9r1MNSNR64wXizXA8avzvDMMaJMiN1keLfntGjqV2yo6dPhvvc0YApQKpFXCmYsNSYBaHPQDQ5”
  user_claim: cid
  roles_claim: croles
  header_name: Authorization

We are only defining 3 groups RO/RW/Admin. We use JWT for authentication and send customer id as part of the JWT. In the tenancy, we are defining index based on the @{user}. This means when Customer A logs in his kibana index and indices would be based on his customer id. Any dashboards he defines would be part of this customer id kibana index.

We are expecting this configuration would scale for any number of customers and we dont have to change ROR configuration for every new customer we onboard.

Also, i know there is a feature pending for parametrizing JWT fields into the groups. This would help in adding more rules based on our attributes.

Please let us know if this is a supported configuration and this would help expedite our qualification of the plugin.

Thanks,
Ravikanth

2

Hello @ravjanga,

This is a really nice solution: great use of the dynamic variables and the concept of tenancies and kibana access levels are potentially very well applied.

However I notice how you are binding the indices and kibana_index rules to the @{user}. This would flatten the concept of user and tenancy together. i.e.

1 customer -> 1 set of indices -> 1 kibana index -> 1 user (with either rw or ro access level)

As opposed to what I thought you want:

1 customer -> 1 set of indices -> 1 kibana index -> N users (with either ro or rw access level)

Can you confirm which is your objective?

[EDIT] I think you want the second option, and in order to do so, you really need the JWT claims to be used in dynamic variables i.e. @{jwt:customer_id} to be used in the indices and kibana_index rules in the same place where you now have @{user}.

So yes for now the settings look great, but you’re limited by the unavailability of claims in the dynamic variables.

Correct?

3

Hello Simone,

Is it ok if I can shoot you an offline email on how we are planning to implement this multi tenancy using the explained approach?

Yes we are using the dynamic variables. But unfortunately we are limited by the fact that only 1 variable is available which is @user.

Thanks,
Ravikanth

4

@ravjanga sure, you know how to reach me :slight_smile:

5

@ravjanga
Hi

I am trying to achieve somthing similar as you using jwt. Would you mind posting your config if you solved this? Or perhaps sending it to me in a PM if you don’t want to shar it with the forum?

Thanks

6

Hello Peter,

Let me know if the below snippet is useful. Yes, we have solved this using simpler configuration.

    - name: "::DEFAULT_TENANT_READONLY::"
      kibana_access:ro
      kibana_index: ".kibana-default-@{user}"
      verbosity: error
      jwt_auth:
        name: "JWT_DEFAULT"
        roles: ["viewer"]
      indices: [".kibana-default-@{user}", "*@{user}*"]
      kibana_hide_apps: ["readonlyrest_kbn", "timelion", "kibana:dev_tools", "kibana:management"]

    - name: "::DEFAULT_TENANT_READWRITE::"
      kibana_access: rw
      kibana_index: ".kibana-default-@{user}"
      verbosity: error
      jwt_auth:
        name: "JWT_DEFAULT"
        roles: ["writer"]
      indices: [".kibana-default-@{user}", "*@{user}*"]
      kibana_hide_apps: ["readonlyrest_kbn", "timelion", "kibana:dev_tools"]

    - name: "::DEFAULT_TENANT_ADMIN::"
      kibana_access: admin
      kibana_index: ".kibana-default-@{user}"
      verbosity: error
      jwt_auth:
        name: "JWT_DEFAULT"
        roles: ["admin"]
      indices: [".kibana-default-@{user}", "*@{user}*"]

    jwt:
    - name: JWT_DEFAULT
      signature_algo: RSA
      signature_key: "*******"
      user_claim: userid
      roles_claim: roles
      header_name: Authorization
2 Likes