[GUIDE] RoR : Right access definition for old version of Kibana 4 and ES 2.x

Cookbooks & Guides
1

#Segregate rights in kibana for version prior 5.x

  • Updated to align new versions compatibilty

  • In case of you did not migrated yet to kibana and elasticsearch 5.x, you can not benefit of the great new feature in ReadOnlyRest Pro, regarding the ability to define rights in kibana searches, visualizations and dashboards.

It means you have the risk to see one user overwritting the Dashboard created by an another one, but you would like to see your users having the ability to create/delete/update their kibana objects.

Of course we recommend you to upgrade as soon as possible, but until you do it, find here a workaround (has been tested on ROR (ReadOnlyRest) up to 1.16.14_pre1 , up to Kibana 4.5.6 and up to elasticsearch 2.4.5).

##Requirements:

  • elasticsearch 2.x,
  • kibana 4.x,
  • ROR plugin > 1.11

Instructions

  • Step 1 : Define a naming convention
  • Step 2 : Implement the work around in Readonlyrest plugin configuration part in elasticsearch.yml ( bah yep, you would not need to do that in latest version :slight_smile: )
  • Step 3 : Restart your elasticsearch

Step 1: Naming convention

Here you will find a strategy, not the best, not the worst, but it works :slight_smile:

Naming convention to communicate to your users :
In the future, to create a search, name it as :
SEAR_appname SomeMoreDescriptionIfNeeded
In the future, to create a visualization, name it as :
VISU_appname SomeMoreDescriptionIfNeeded
In the future, to create a dashboard, name it as :
DASH_appname SomeMoreDescriptionIfNeeded
Of course you can decide to replace appname by username and you could obtain
SEAR_fred list error based on criteria 4

on my side I used to use indicename as reference, it is your liberty of choice.

Now, how it can work ? well it is in configuration part

###Step 2: ROR elasticsearch.yml configuration

Currently you should have defined a ROR block, to define acces to a user : (like below)

    - name: Fabrice (read)
      # auth_key is good for testing, but replace it with `auth_key_sha1`!
      auth_key: fabrice:fabrice
      type: allow
      kibana_access: rw
      indices: ["<no-index>", "watcher", "watcher_alarms", ".kibana*", "logstash_paloalto*","home"]

In this block, the user has full access on all actions in Kibana.

then just modify the entry like below

    - name: Fabrice (create Dashboard)
      # auth_key is good for testing, but replace it with `auth_key_sha1`!
      auth_key: fabrice:fabrice
      type: allow
      methods: [POST,DELETE]
      uri_re: ^/.kibana/.*?((?i)VISU_|DASH_|SEAR_)(?i)fabrice.*
      kibana_access: rw
      
    - name: Fabrice (read)
      # auth_key is good for testing, but replace it with `auth_key_sha1`!
      auth_key: fabrice:fabrice
      type: allow
      kibana_access: ro
      indices: ["<no-index>", "watcher", "watcher_alarms", ".kibana*", "logstash_paloalto*","home"]

In this new configuration with these 2 block ( and order is really important), rights on kibana are defined by the 1st block, for the objects named by the uri_re : here the user can create/update/delete only some stuff with name structured like "SEAR_fabrice error 17 detected".

Second block maintain access rights for indices, and only readonly access to other search/visualization/dashboard created by others ( this is not a security issue, since data access is managed by indices access, not dashboard access.

Step 3: Well, save your config elasticsearch.yml and restart the service.

1 Like