Authentication and access control support

[elvarb]

Now that Kibana is its own web server it would be possible to support authentication, kerberos for example.

I have not tried the beta yet so I'm not sure how the Elasticsearch integration is. Would it be possible now to create access controls based on tags? (that is if the query is reverse proxied through the Kibana webserver and not a direct http query to the Elasticsearch cluster.

[Pytlicek]

+1 for this feature.
I think it is good to have authentication.

[dsvetlov]

+1 too.

[CullyB]

This would be very useful;
One idea we have explored is forcing users to a filtered index alias based on ldap group membership. =

[TiNico22]

+1
Local file, kerberos and ldap auth and you support 95% of authentication option

[sahilthapar]

👍

[blockv]

+1 too

[damm]

Authorization is quite complex sometimes; external OAuth2 Adapter? Do you support OAuth2 natively? what about HTTP Authentication or using limit_get?

I'm going to see people deploy this as a reverse proxy through nginx I suspect and being able to lock it down is vital. We don't want to open a new 'elasticsearch' endpoint to be abused.

[TiNico22]

Why not using CAS ? seems to be a good candidate for that kind of job.
http://jasig.github.io/cas/4.0.0/index.html

[damm]

Radius, LDAP, HTTP Based Authentication (http_auth, limit_get, openid, Oauth2) all seem fine Kerberos will be fun with 2 implementations or just 1?

[zabbal]

Why not start with simplest possible option: http-digest using .htpasswd - all the tools are there, testing is trivial. Later on things like per-tag auth, ldap and fancy oauth2-whatever could be added. The most pressing thing is to make kibana usable out-of-the-box without need for external server to babysit its insecurity.

[damm]

htpasswd isn't that secure anymore; unless you use SSL you can capture the hashed contents and reverse them with a little cpu power.

[zabbal]

Setting up TLS termination is trivial: you can use pound or stunnel with few lines of simple configuration.
Setting up reverse proxy which would do authentication for insecure applications like kibana is way more complex and hence have higher chance for errors - see #1772 for example.

[damm]

Really all we need here is just to have a updated example of an nginx vhost like we had in kibana 3; and let the users sort out the rest.

Like I mentioned in #1559 (comment) there's lots of forms. If your provide a basic service we can lock it down ourselves.

Unless there is per user Dashboards I don't see really the point of authentication in Kibana itself. Document how to secure it; sure.

[elvarb]

There is only one method available to limit access, not just provide authentication. That is the one that uses nginx to rewrite the query to a alias in elasticsearch. This is not a solution to go forward.

I agree that we can do authentication with reverse proxies of choice, definitely a good solution.

What has changed now is that we have the option to do access controls natively and for that to make sense we have to add authentication as well.

[wjimenez5271]

+1

Sinatra has support natively for http authentication, ideally use this to provide role based access control that is tightly integraed with Kibana

[natefaerber]

I feel like ElasticSearch has to be involved here. Implementing AAA for indexes would be a huge step and cover most user cases, IMO.

[damm]

Elasticsearch does not provide authentication itself.

That said one way you could provide authentication is; enable the authentication plugin to ES and configure users and then make Kibana use those users. But some orgs are different; LDAP, Kerberos, Radius ... I deploy OAuth2 but I can see value in Radius or LDAP support as well.

See how many buttons are on https://github.com/sahat/satellizer just imagine once we add the rest?

[natefaerber]

@damm , but this doesn't handle authorization. There are many ways I can be authenticated. I want to control who is authorized to view what. That's the second A of AAA.

[damm]

@natefaerber that's what https://github.com/codelibs/elasticsearch-auth should be for. Standard HTTP Auth won't limit unless you do it yourself somehow.

[natefaerber]

@damm , nice. Any idea when elasticsearch-auth and Kibana will meet?

[TiNico22]

Maybe a shield agent may do the job ?http://www.elasticsearch.org/blog/shield-know-security-coming-soon/

[damm]

I guess @TiNico22 answered your question @natefaerber

[azerafati]

I think it would be also proper to limit users, for example I have users that I want to be able to only access a limited type of logs and a defined dashboard only!! so yea, a security system is sooo much needed for kibana to turn into the ultimate tool, tanx

[Palmjust]

+1
We want a central all logs and show anything to the operator. But we have also developer that should only access to there application logs.

[megastef]

@Palmjust if you don't like to wait pls. check Logsene by Sematext http://sematext.com/logsene/ - we did already kibana4 integration and have role based access control, app and account sharing for large teams + free plan and startup program for small teams.

[tangyong]

+1

[sanjay1966]

+1, and need it urgently :).

[bluepuma77]

It's so awesome (irony). Not only does Kibana have no internal authentication system, so everyone has access to it's data, but it also has a proxy to elasticsearch - enabled by default. So even if you set up elastic to use only localhost, Kibana will expose it at '/elasticsearch' (try /elasticsearch/_cat/indices?v). What happened to security by design?

Maybe the 'Installation Steps' should tell people to put the server only on localhost and use an authenticating proxy like Apache. And to disable the proxy in app.js if they don't want their Kibana users to mess and potentially delete the raw data in elastic.

[rtoma]

@bluepuma77: that is bad! Thanks for spotting & sharing this.

@rashidkpc: could you please share with us the official plans for adding authentication to Kibana4, so all open-source users can secure themselves?

[damm]

Locking down / Exposing Elasticsearch / Kibana in a Global work environment is unique.

P.S. I think security by design has pretty much fallen away. Marketing / Sales trying to sell your product before you've designed it (finished it) doesn't help and pretty much rots away any good reason to be secure if your not careful.

[rashidkpc]

Closing in favor of #3904

[kadishmal]

Closed this issue in favor of what? The links points to this very same issue.

[ssoto]

I think the closing has been a mistake. There isn't any doubt about authentication need after 1 year discussing.

Maybe the new issue is not 1559... I hope

[rtoma]

@rashidkpc created issue #3904 "Kibana authentication layer, phase 1". A design for auth-only targeted for 4.2.0. I am pretty sure he meant to link to that issue.

I suggest we all read #3904 and add feedback on that design.

Note: its only about authentication, so does not answer the need for limiting access to the settings. I really hope "Kibana authhorization layer, phase 1" will follow shortly.

[chevectra87]

+1

[ghost]

+1

[kaikao]

+1

[Malu44]

+1

[sistemasokn]

+1

[shellfly]

+1

[nilsga]

+1

[thebhushanp]

+1

[Shkarbatov]

+1

[joshrendek]

+1

[penekk]

waiting for it as well +1

[stackoverflower]

• 1

[sscarduzio]

I made myself a plugin for this: multi user, read only dashboards, hide indices, etc :)
https://github.com/sscarduzio/elasticsearch-readonlyrest-plugin

[vrecan]

👍

[dfaropennetwork]

Yes please +1