LDAP authenticated tenant


#1

Trying to do an all-in-one rule and it almost works.

This works perfectly up to the RoR Pro level. Logging into Kibana will use the .kibana.public index.

- name: "::Public::"
  ldap_auth:
    name: "ldap1"
    groups: ["kibanapublic"]
  kibana_access: rw
  kibana_hide_apps: ["readonlyrest_kbn"]
  kibana_index: ".kibana.public"

However to get the RoR Enterprise multi-tenancy there needs to be the group variable (tenant name seems to be derived from the ‘group’ variable in the same ACL block as the ‘kibana_index’ variable?)
This does not work after adding the ‘group’ variable and fails with a [ldap_authorization->true, groups->false] messages.

- name: "::Public::"
  groups: ["Public"]
  ldap_auth:
    name: "ldap1"
    groups: ["kibanapublic"]
  kibana_access: rw
  kibana_hide_apps: ["readonlyrest_kbn"]
  kibana_index: ".kibana.public"

Is there any other way to make this work? I cannot get split ACL’s as the LDAP group doesn’t seem to feed into the ‘group’ variable for the Kibana multitenancy like local users do (unless I am missing something?). Any possibility of having the tenant name used in Kibana moved to a ‘tenant_name’ variable? If ‘tenant_name’ exists then use it, if not then use ‘groups’ for the tenant name.

My use case is an enterprise environment where the tenants are organizational groups mostly to organize the thousands of visualizations that build up. For example:

  • LDAP group 1 of users to see indexes ABC and use .kibana.publicindex with RO access
  • LDAP group 2 of users to see indexes ABCDE and us the same .kibana.publicindex with RW access
  • Both sets of users see the same tenant name of “Public” even though in RoR they are two different tenants.

(Simone Scarduzio) #2

Great analysis @brian, what you noticed is all confirmed. Basically the LDAP authorization is not filling up the metadata like the local groups rule does.

This behaviour was noticed by @ld57 last week as well, and should not be a huge amount of work to fix. Will update on this.