Hello,
My company is a ReadonlyREST Enterprise subscriber.
In a multitenancy kibana configuration based on ldap groups, where each team uses its tenancy kibana secured by an ldap group managed by the team itself.
Is there a simple method to give one or more other teams (other AD group) the possibility of accessing all tenancy?
I am looking for the possibility of giving access to all tenancy to cross-functional teams such as support teams.
Hello @erms77,
The answer is… Maybe! Show me your ACL to see if it’s feasible.
Are you using dynamic varibles inside kibana_index rule to define tenancies dynamically with LDAP groups?
Hello Simone,
No at the moment we do not use dynamic variables in the construction of our RoR configuration.
(Our RoR configuration is generated by ansible)
Below is a concise example of our conf (in reality we have about 100 tenancies)
What we would like to do is allow a third team (example group AD_GROUP_USER3_MAIN) to access the other two tenancy without having to add them to the AD group of the other two.
readonlyrest:
enable: true
audit_collector: true
audit_index_template: "'audit_logs'-yyyy-MM-dd"
response_if_req_forbidden: Access refused. Please authenticate yourself.
prompt_for_basic_auth: false
access_control_rules:
- name: "::KIBANA-SRV::"
auth_key: "kibana:password_example"
verbosity: error
- name: "::ADMIN::"
kibana_access: admin
verbosity: error
ldap_auth:
name: ldap-server
groups: ["AD_GROUP_ADMIN"]
- name: "::USER1_MAIN::"
kibana_access: rw
verbosity: error
kibana_index: .kibana_user1
kibana_hide_apps: ["readonlyrest_kbn", "Analytics|Overview", "Analytics|Canvas", "Analytics|Maps", "Enterprise Search"]
ldap_auth:
name: ldap-server
groups: ["AD_GROUP_USER1_MAIN"]
indices: ["logs_user1*", ".kibana_user1"]
- name: "::USER2_MAIN::"
kibana_access: rw
verbosity: error
kibana_index: .kibana_user2
kibana_hide_apps: ["readonlyrest_kbn", "Analytics|Overview", "Analytics|Canvas", "Analytics|Maps", "Enterprise Search"]
ldap_auth:
name: ldap-server
groups: ["AD_GROUP_USER2_MAIN"]
indices: ["logs_user2*", ".kibana_user2"]
ldaps:
- name: ldap-server
host: ad-ldap-server.example.fr
port: 636
ssl_enabled: true
ssl_trust_all_certs: true
bind_dn: CN=our,OU=path,OU=to,DC=group,DC=com
bind_password: password_example
search_user_base_DN: DC=group,DC=com
user_id_attribute: "some_id"
search_groups_base_DN: OU=path,OU=to,DC=group,DC=com
unique_member_attribute: "some_member_attribute"
connection_pool_size: 10 # optional, default 30
connection_timeout_in_sec: 300 # optional, default 1
request_timeout_in_sec: 60 # optional, default 1
cache_ttl_in_sec: 1200OK, I would map LDAP groups to local groups, and add a new AD_GROUP_ALL_TENANCIES to the LDAP server.
Something along the lines of the following:
readonlyrest:
enable: true
audit_collector: true
audit_index_template: "'audit_logs'-yyyy-MM-dd"
response_if_req_forbidden: Access refused. Please authenticate yourself.
prompt_for_basic_auth: false
access_control_rules:
- name: "::KIBANA-SRV::"
auth_key: "kibana:password_example"
verbosity: error
- name: "::ADMIN::"
kibana_access: admin
verbosity: error
groups: ["Admins"]
- name: "::USER1_MAIN::"
kibana_access: rw
verbosity: error
kibana_index: .kibana_user1
kibana_hide_apps: ["readonlyrest_kbn", "Analytics|Overview", "Analytics|Canvas", "Analytics|Maps", "Enterprise Search"]
groups: ["User1_main"]
indices: ["logs_user1*", ".kibana_user1"]
- name: "::USER2_MAIN::"
kibana_access: rw
verbosity: error
kibana_index: .kibana_user2
kibana_hide_apps: ["readonlyrest_kbn", "Analytics|Overview", "Analytics|Canvas", "Analytics|Maps", "Enterprise Search"]
groups: ["User2_main"]
indices: ["logs_user2*", ".kibana_user2"]
users:
- username: "*"
groups: ["User1_main"]
ldap_auth:
name: ldap-server
groups: [AD_GROUP_USER1_MAIN, AD_GROUP_ALL_TENANCIES]
- username: "*"
groups: ["User2_main"]
ldap_auth:
name: ldap-server
groups: [AD_GROUP_USER2_MAIN, AD_GROUP_ALL_TENANCIES]
- username: "*"
groups: ["Admins"]
ldap_auth:
name: ldap-server
groups: [AD_GROUP_ADMIN, AD_GROUP_ALL_TENANCIES]
Unfortunately, the version of ror we are using (1.28.2) does not allow the use of wildcard in the username configuration.
Error: Failed to save the security settings: "Cannot reload new settings: Errors:\nusers definitions must have unique identifiers. Duplicates: *"
Yes, 1.28.2 is ancient. The wildcards were not there in the username configurations. 
By the way, we are about to release an even further improved groups mapping feature. There will be documentations and examples in our docs website as well, I will link to this thread once it’s ready.
So what I would do, is wait a day or two, upgrade to 1.35.0 and go with the above suggested configuration (or a refined version of it, once taken in consideration the coming improvements).
What do you think?
ROR 1.35.0 with detailed local → external groups mapping was released. The feature description can be found here: https://github.com/beshu-tech/readonlyrest-docs/blob/master/elasticsearch-details/groups-rule-mapping.md