Not clear how to use multi-tenancy with dynamic variables

Users Feedback
1

I have been going down the path of multi-tenancy where all tenant info is provided by the proxy. (We have way too many, and too fast changing tenants to maintain static config files).

eg,

        - name: user-plant--kibana
          headers:
            - x-vi-plant:*
          proxy_auth: '*'
          kibana_hide_apps: "{{ kibana_ror_plant_hide_apps }}"
          kibana_access: ro
          kibana_index: ".kibana"
          indices:
            - ".kibana"

        - name: user-plant--data
          headers:
            - x-vi-plant:*
          proxy_auth: '*'
          kibana_hide_apps: "{{ kibana_ror_plant_hide_apps }}"
          indices:
            - kibana_sample_data_ecommerce
          filter: |
            {
              "term": {"customer_gender": "@{x-vi-plant}"}
            }

The only docs I have found on how to do multi-tenant (with a selector) is [ROR ENTERPRISE] Feature Preview: Group/Tenancy Selector (Video). But this uses hard-coded values for tenants. Is that the only way to define tenants and for an admin to switch tenants?

Unless I’m missing something https://github.com/beshu-tech/readonlyrest-docs/blob/master/multitenancy_guide.md does not really document how to define tenants and enable the tenancy selector.

2

Even if we can’t use the tenancy selector, how to get a rule to use a tenant specific kibana index?

I’ve tried rules like

- name: user-plant--kibana
          headers:
            - x-vi-plant:*
          proxy_auth: '*'
          kibana_hide_apps: "{{ kibana_ror_plant_hide_apps }}"
          kibana_access: ro
          kibana_index: ".kibana_@{x-vi-plant}"
          indices:
            - ".kibana_@{x-vi-plant}"

But this still tries to use .kibana not, eg .kibana_foo or .kibana_bar.

3

The docs on kibana_index say

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

But I don’t see anything about kibana.index in readonlyrest-docs/kibana.md at master · beshu-tech/readonlyrest-docs · GitHub.

Of course I see the kibana docs for kibana.index, but how would that be used to specify an index per tenant?

4

Maybe all this functionality should be moving over to Spaces…?

5

CGR is not set, so I guess that is why the kibana_index is not being used.

[2018-12-23T02:12:57,267][INFO ][tech.beshu.ror.acl.ACL   ] [s-ror-es-1] FORBIDDEN by default req={ ID:264597514-59383591#84, TYP:SearchRequest, CGR:N/A, USR:john, BRS:false, KDX:null, ACT:indices:data/read/search, OA:10.11.136.187, DA:10.11.136.187, IDX:.kibana, MET:POST, PTH:/.kibana/_search?size=1000&from=0, CNT:<OMITTED, LENGTH=245>, HDR:{x-forwarded-user=john, x-vi-plant=MALE, Connection=keep-alive, content-type=application/json, Host=10.11.136.187:9200, Content-Length=245}, HIS:[svc-consul->[auth_key->false]], [svc-kibana->[auth_key->false]], [user-admin->[auth_key->false]], [user-plant--kibana->[kibana_access->true, headers->true, indices->false, proxy_auth->true]], [user-plant--data->[headers->true, indices->false, proxy_auth->true]] }

But that still leaves the issue of how to get the group set without hard-coding in the rules?

I looked at the groups provider, but it seems that only the username is passed to it. In my case, I just came thru a proxy that had full access to the jwt and set headers. I really don’t want to bounce back out again to get a group which would just be the same as x-vi-plant in an existing header.

6

CGR seems to have been a decoy. I was using the kibana test data kibana_sample_data_ecommerce and the field customer_gender as a stand-in for plant. But the value I was passing in for x-vi-plant was “MALE” – uppercase, which is not a valid name for an index. This was of course logged by elasticsearch, but I was not looking at that log (in the terminal just below the ror log :frowning: ).

7

I found I had to have two rules for kibana. Is there a way to not require .kibana at all?

        - name: user-plant--kibana-rw
          headers:
            - x-vi-plant:*
          proxy_auth: '*'
          kibana_hide_apps: "{{ kibana_ror_plant_hide_apps }}"
          kibana_access: rw
          kibana_index: ".kibana_@{x-vi-plant}"
          indices:
            - ".kibana_@{x-vi-plant}"

        - name: user-plant--kibana-ro
          headers:
            - x-vi-plant:*
          proxy_auth: '*'
          kibana_hide_apps: "{{ kibana_ror_plant_hide_apps }}"
          kibana_access: ro
          kibana_index: ".kibana_@{x-vi-plant}"
          indices:
            - ".kibana"
            - ".kibana_@{x-vi-plant}"
8

A Kibana session should always have one and only one kibana index. The fact that in 6.5.x we have some calls being made to the default kibana index is a bug and we are at work trying to fix it.

Your workaround with the double block sounds legit.

about tenancy switcher using headers as authorization
ROR cannot anticipate the whole set of headers values that the proxy can pass to it. And as a matter of fact, they are seen as headers, not groups. This is why with this configuration, you cannot have the tenancy selector menu.

Normally, with local groups and LDAP authorization, the information ROR can detect a user can belong to N > 1 tenancies, and introduces the drop down menu automatically.