Kibana4 and Search-Guard

[Brian_Sanders]

I am interested in search-guard so I can provide index level separation between groups of users. I really don’t want to run multiple elasticsearch nodes just to give each user group their own indexes.

This seems like it might do what I need, but I don’t fully understand how this works when combined with Kibana4. Can I setup http auth before Kibana, and have this passed all the way through to the elasticsearch where this plugin can make decisions based on who logged into kibana?

Does this provide anything in the way of kibana4 integration such that users (or user groups) would have their own .kibana index so they could share saved searches etc? If not, I believe I could still make this work by just running multiple instances for Kibana per user group, each configured to talk to the correct .kibiana index. I just need to know that my first concern about passing users through to elastic search will allow me to control what these user groups have access to.

Thank you!

[Nathan_Young]

Hi Brian,

We’re in a similar situation to you, currently Kibana4 doesn’t support user separation, it needs to be setup with an account that has access to all indices etc. Our workaround is similar in that we have a Kibana instance per group each with their own .kibana index, they could possibly all reference the same index if we utilised dls but that’s probably not really worth doing.

···

On Thursday, June 18, 2015 at 8:30:22 PM UTC+1, Brian Sanders wrote:

I am interested in search-guard so I can provide index level separation between groups of users. I really don’t want to run multiple elasticsearch nodes just to give each user group their own indexes.

This seems like it might do what I need, but I don’t fully understand how this works when combined with Kibana4. Can I setup http auth before Kibana, and have this passed all the way through to the elasticsearch where this plugin can make decisions based on who logged into kibana?

Does this provide anything in the way of kibana4 integration such that users (or user groups) would have their own .kibana index so they could share saved searches etc? If not, I believe I could still make this work by just running multiple instances for Kibana per user group, each configured to talk to the correct .kibiana index. I just need to know that my first concern about passing users through to elastic search will allow me to control what these user groups have access to.

Thank you!

[searchguard_google_group]

were working on dedicated kibana documention for search guard as well as an demo for that.
Pls. be patient, will come within the next 2 weeks ...

···

Am 18.06.2015 um 21:30 schrieb Brian Sanders <brian.sanders@gmail.com>:

I am interested in search-guard so I can provide index level separation between groups of users. I really don't want to run multiple elasticsearch nodes just to give each user group their own indexes.

This seems like it might do what I need, but I don't fully understand how this works when combined with Kibana4. Can I setup http auth before Kibana, and have this passed all the way through to the elasticsearch where this plugin can make decisions based on who logged into kibana?

Does this provide anything in the way of kibana4 integration such that users (or user groups) would have their own .kibana index so they could share saved searches etc? If not, I believe I could still make this work by just running multiple instances for Kibana per user group, each configured to talk to the correct .kibiana index. I just need to know that my first concern about passing users through to elastic search will allow me to control what these user groups have access to.

Thank you!

--
You received this message because you are subscribed to the Google Groups "Search Guard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com.
To post to this group, send email to search-guard@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/044bbc02-6432-44f8-b17d-78bbda825b11%40googlegroups.com\.
For more options, visit https://groups.google.com/d/optout\.

[karol_ryzner]

Hi,

Do you still plan to provide documentation for kibana?
I think there are many people waiting for it.

Karol

···

[searchguard_google_group]

sure

···

Am 17.07.2015 um 15:29 schrieb karol ryzner <karol.ryzner@gmail.com>:

Hi,

Do you still plan to provide documentation for kibana?
I think there are many people waiting for it.

Karol

--
You received this message because you are subscribed to the Google Groups "Search Guard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com.
To post to this group, send email to search-guard@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/287a5a91-a348-4dde-a8c1-7a25536e5540%40googlegroups.com\.
For more options, visit https://groups.google.com/d/optout\.

[Brian_Sanders]

I was able to setup my searchguard to auth from HTTP headers, and therefore pass the auth through kibana. It is a quite complex, and frankly I hope there is a cleaner way that I just didn’t know how to setup.

For anyone else curious, my current setup required doing the following:

-Users connect to http webserver with nginx ldap authentation.

–If user auths succeed, HTTP headers entered for username and request passed to the actual kibana port on localhost

-Kibana is configured to talk to another local nginx host and not the elasticsearch cluster directly

–Nginx checks for the HTTP auth header, and if missing, inserts one with “kibana” as the user. (the only requests which do not have http auth are ones that kibana it self generates when trying to access it’s own settings on startup). These requests are then forwarded to the actual elasticsearch cluster.

-search guard in the elasticsearch is configued with all the following settings for authorization/authentication

searchguard.http.xforwardedfor.header: X-Forward-For

searchguard.http.xforwardedfor.trustedproxies: 127.0.0.1

searchguard.http.xforwardedfor.enforce: false

searchguard.authentication.authentication_backend.impl: com.floragunn.searchguard.authentication.backend.simple.AlwaysSucceedAuthenticationBackend

searchguard.authentication.authorizer.impl: com.floragunn.searchguard.authorization.simple.SettingsBasedAuthorizator

searchguard.authentication.http_authenticator.impl: com.floragunn.searchguard.authentication.http.proxy.HTTPProxyAuthenticator

searchguard.authentication.authorization.settingsdb.roles.kibana: [“admin”]

searchguard.authentication.authorization.settingsdb.roles.: [“admin”]

searchguard.authentication.authorization.settingsdb.roles.: [“dev”]

searchguard.authentication.proxy.header: x-authenticated-user

searchguard.authentication.proxy.trusted_ips: 127.0.0.1

I am still hoping there is a better way. Running a second nginx head just to give requests coming from Kibana access to it’s own index is quite complex. Still using this I can auth users from LDAP, then group them manually in the configuration file and create ACL’s based on these groups and specific indexes. So for example a dev group could have access to the dev index while admin’s get all.

I would love to know if there is a better way. I don’t know that I can do my groups from LDAP since I am doing HTTP auth for the user authentication. Is that possible?

···

On Sunday, July 19, 2015 at 4:44:55 PM UTC-4, SG wrote:

sure

Am 17.07.2015 um 15:29 schrieb karol ryzner karol....@gmail.com:

Hi,

Do you still plan to provide documentation for kibana?

I think there are many people waiting for it.

Karol

–
You received this message because you are subscribed to the Google Groups “Search Guard” group.

To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.

To post to this group, send email to search...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/287a5a91-a348-4dde-a8c1-7a25536e5540%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Rocio_Rama]

Hello,
Any documentation about how to setup kibana?
Thanks in advance

···

On Tuesday, July 28, 2015 at 8:52:41 PM UTC+2, Brian Sanders wrote:

I was able to setup my searchguard to auth from HTTP headers, and therefore pass the auth through kibana. It is a quite complex, and frankly I hope there is a cleaner way that I just didn’t know how to setup.

For anyone else curious, my current setup required doing the following:

-Users connect to http webserver with nginx ldap authentation.

–If user auths succeed, HTTP headers entered for username and request passed to the actual kibana port on localhost

-Kibana is configured to talk to another local nginx host and not the elasticsearch cluster directly

–Nginx checks for the HTTP auth header, and if missing, inserts one with “kibana” as the user. (the only requests which do not have http auth are ones that kibana it self generates when trying to access it’s own settings on startup). These requests are then forwarded to the actual elasticsearch cluster.

-search guard in the elasticsearch is configued with all the following settings for authorization/authentication

searchguard.http.xforwardedfor.header: X-Forward-For

searchguard.http.xforwardedfor.trustedproxies: 127.0.0.1

searchguard.http.xforwardedfor.enforce: false

searchguard.authentication.authentication_backend.impl: com.floragunn.searchguard.authentication.backend.simple.AlwaysSucceedAuthenticationBackend

searchguard.authentication.authorizer.impl: com.floragunn.searchguard.authorization.simple.SettingsBasedAuthorizator

searchguard.authentication.http_authenticator.impl: com.floragunn.searchguard.authentication.http.proxy.HTTPProxyAuthenticator

searchguard.authentication.authorization.settingsdb.roles.kibana: [“admin”]

searchguard.authentication.authorization.settingsdb.roles.: [“admin”]

searchguard.authentication.authorization.settingsdb.roles.: [“dev”]

searchguard.authentication.proxy.header: x-authenticated-user

searchguard.authentication.proxy.trusted_ips: 127.0.0.1

I am still hoping there is a better way. Running a second nginx head just to give requests coming from Kibana access to it’s own index is quite complex. Still using this I can auth users from LDAP, then group them manually in the configuration file and create ACL’s based on these groups and specific indexes. So for example a dev group could have access to the dev index while admin’s get all.

I would love to know if there is a better way. I don’t know that I can do my groups from LDAP since I am doing HTTP auth for the user authentication. Is that possible?

On Sunday, July 19, 2015 at 4:44:55 PM UTC-4, SG wrote:

sure

Am 17.07.2015 um 15:29 schrieb karol ryzner karol....@gmail.com:

Hi,

Do you still plan to provide documentation for kibana?

I think there are many people waiting for it.

Karol

–
You received this message because you are subscribed to the Google Groups “Search Guard” group.

To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.

To post to this group, send email to search...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/287a5a91-a348-4dde-a8c1-7a25536e5540%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.