Kibana.index in KBN 8.X+ROR Free

1

Hi,
I’m currently using Elastic Stack version 7.17.X with ROR Free and have started considering upgrading to 8.X. I actively use several Kibana instances to separate index patterns, dashboards, visualizations and saved queries.

In version 8.X, the kibana.index parameter was originally removed from the Kibana configuration, but I see in the Readonlyrest documentation and changelog that it has been restored for both 7.X and 8.X.
Therefore, I have a question, how should I properly understand this section of documentation in case of ROR Free? How is it handled if multi-tenancy is unavailable?

image
image624×179 18.9 KB

Will I still be able to use kibana.index in 8.X for it to work like in 7.X or not and the only option will be to migrate to one or more kibanas (sharing common .kibana index) and many Spaces as unfortunately recommended for 8.X?
Additional question, is there any way in ROR to restrict permissions to create/delete Space for only an unrestricted or admin user?

2

Hello @mikeIT

I have a question, how should I properly understand this section of documentation in case of ROR Free? How is it handled if multi-tenancy is unavailable?

It will be handled the same as before 8.x, so you can define your custom Kibana index as usual. We added support for kibana.index so it works the same way as for Kibana 7.x.

Will I still be able to use kibana.index in 8.X for it to work like in 7.X or not

You will still be able to use it

Additional question, is there any way in ROR to restrict permissions to create/delete Space for only an unrestricted or admin user?

There are two ways to achieve it:

  1. You could use hide_apps Kibana related ACL rule. It’s for a pro license only. Thanks to it, you will be able to hide the space management page for specific users
  2. You can use uri_re and methods HTTP level rules in combination with a forbid type, for example:
  -   name: USER_DEFAULT_FORBID_SPACE
      uri_re: ["^.*/_doc/space.*", "^.*/_create/space.*"]
      methods: [PUT, DELETE]
      type: forbid
      auth_key: user2:dev
      kibana:
          access: rw

  -   name: USER_DEFAULT
      auth_key: user2:dev
      kibana:
          access: rw
3

Thank you very much for the answers and examples.
I see that restriction really works as expected but I’ll try to test it more :slight_smile:

1 Like
4

Hello, In reference to the above topic and the update of the Elastic stack to version 8.X, I have one additional question about this part of the documentation regarding patching ES plugin

:warning:IMPORTANT: for Elasticsearch 8.3.x or newer, the patching operation requires root user privileges

What type of ‘root privileges’ should user installing and patching/unpatching ROR plugin have?

5

By root privileges*,* we mean OS-level root. Please run the ror-tools patch/unpatch commands with sudo (or as root) because they replace files in the Elasticsearch installation.

6

I understand. But my concern is, as ‘sudo user’ what type of specific OS-level privileges should that user have?
Currently with for example Elastic 7.17.29 when installing and patching Elasticsearch I noticed that only files from:
/elasticsearch_install_dir/lib/elasticsearch-7.17.29.jar
/elasticsearch_install_dir/plugins/readonlyrest/*
had changed. Does that mean that with ES 8.3+ some other Elasticsearch files may also be modified for Readonlyrest plugin patch?

7

Yes. Different ES versions (and KBN too) require patching different ES internal files.
We don’t list all the patched files in our documentation, but in the case of ES, you can check them in the source code.