Securing kibana with free ReadonlyREST version!


(Milad Hamid) #1

Hi,

Is it possible to have username and password for Kibana with community version of ReadonlyREST?


(Ld57) #2

Hello,

in fact, RoR free version secures only elasticsearch, not kibana.
but, as limiting access to data in elasticsearch, you can limit access to data through kibana by the same way.

if you want security enforcement on kibana, you should look for pro version at least.
you ll get ride of basic mode authentication, and also will be able to secure kibana content like dashboard and co.

You should see the difference between version in https://readonlyrest.com/#chart

Kr

Fred


(Alexandru) #3

It’s not clear for me…

I have this setup: multiple “tenants” in elasticsearch. each tenant will write data in a index data-tid* and for each client I have a Kibana instance that is saving all data in an index named kibana-tid.

In front of this platform I have a frontend that handles clients login. Once a client is logged in a url link is accesible and it will point to kibana instance for that tenant (using header to authenticate, like a proxy). So all the requests to a kibana ui passes trough this frontend/dashboard and the dashboard proxies the request with valid headers to valid kibana instances (based on logged in user information).

I want to be able to have this setup with the free version of the plugin to:

make one instance of Kibana to be able to:
read/write in indexed: data-tid-* and kibana-tid
no need to multiuser in kibana, since each tenant has its own kibana instance
each kibana should save data into an index kibana-tid

Example:

client(tenant)1: kibana: 10.2.2.3:5601
client(tenant)2: kibana: 10.2.2.3:5602
client(tenant)3: kibana: 10.2.2.5:5601

login to dashboard (http://mydashboard as user1 (tenenat1). After login, press the url link for kibana, you will be redirected to http://tenant1.mydashboard.

Under the hood all requests to http: tenant1.mydashboard are processed, then requests are proxied to 10.2.2.3:5601 with valid header (unique user/pass in elasticsearch for tenant1).

Thanks,
Alex


(Simone Scarduzio) #4

Hi @duculete,
So when you have a new tenant you have to set up a new Kibana server on another port and keep it running? Doesn’t this approach waste a lot of memory? I have the impression that if you run this with more than 10-15 tenants for a year you pay the same price in hosting as you’d pay for ROR Enterprise. Plus all the devops work. Am I right?


(Alexandru) #5

hello,

No problem with resources. We have a mesos solution in place is on demand etc…
On the other side, having 100 clients with complex graphs and dashboard in the same time in one (or more) kibana instances is not ok.

regarding my question, is my setup possible?

btw is there any option to have a free trial licence (14 days) without providing credit card? I have to test this solution on my own and if is ok then I need to propose it to my company and then they will decide if we go for pro.


(Simone Scarduzio) #6

I only partially agree: sure you are spreading the work load on many kibanas, but how evenly? Rarely all the clients have the same workload. Plus, with the proposed setup, none of the clients will enjoy any HA on the Kibana side, despite the deployment of 100 instances. With ROR for Kibana (PRO/Enterprise) you could have 1/10 of the instances with great HA and even load balancing.

If you want a trial, we can arrange something. I will contact you in PM.