Running two Kibana instances with different access types

1

Hi all,

I’m trying to setup ROR to support two Kibana instances;

One instance, the “main” one, would be read-only, except for members of the administration group, who can make changes to dashboard, visualizations, searches, etc.
This instance uses an index named .kibana5

The other instance would be read-write for all. This is a “sandbox” instance where anyone can create new and edit existing objects.
This instance uses an index named .kibana5-sandbox

The general idea is to have a “clean” main instance with well-named and organized objects.
The other would be a playground for devs to create and test visualizations. When they’re happy with the result, the object would be exported and imported in the “main” instance.

I can’t figure out what would be the correct ROR configuration for this. At this point, I’m starting to think I might need to spawn another ES client node with a different ROR configuration for the sandbox instance, since the “kibana_access: ro” directive applies on any Kibana instances.

Here’s my current configuration. The missing piece is how to grant Kibana users access to the .kibana5-sandbox index, so they can save their changes on the sandbox instance.

- name: ":: KIBANA SERVER ::"
  auth_key: "kibana:password"
  hosts: [127.0.0.1]

- name: ":: KIBANA SANDBOX ::"
  auth_key: "kibana-sandbox:password"
  hosts: [127.0.0.1]

- name: ":: KIBANA ADMIN ::"
  kibana_access: rw
  ldap_auth:
      name: "AD"
      groups: [ "LogStash_Admins" ]

- name: ":: RO USERS ::"
  kibana_access: ro
  kibana_hide_apps: [ "readonlyrest_kbn", "kibana:management" ]
  ldap_auth:
      name: "AD"
      groups: [ "LogStash_Users" ]

Any guidance is much appreciated !

Thanks

1 Like
2

Very interesting problem, this is another case in which my users surprise me with clever things I didn’t imagine before. So first of all, @obedard, thanks for sharing it and keep it coming :slight_smile:

A few ways to make it happen:

  • namespace the rules by hosts: run the playground kibana on another network interface (with another local IP) and put the ACL blocks relative to the playground instance as first (each including a hosts: <new interface ip> rule)

  • run a dedicated tiny ES node (no data, no master eligible) bound to localhost:9201, install ROR there and point the secondary Kibana there.

In any case, don’t forget to tell the kibana_access macro the name of the new “.kibana5” index using the kibana_index modifier rule (see docs).

3

Thanks for the suggestions !

I went ahead and setup a second ES client node with ROR and different rules for the playground instance. The second Kibana instance will connect to that ES instance.

Working great so far.

Thanks again, and keep up the awesome work on the plugins !

4

That’s great news! Thanks, yes this plugin seems to be useful to many, super happy about it. I have a lot more ideas, man we are just getting started here :slight_smile: