using certs when accessing kibana's api/saved_objects api not working?

When asking questions, please provide the following information:

  • Search Guard and Elasticsearch version: SG 6.5.3-24/6.5.3-17(kibana), ES@6.5.3 / (same for 6.2.3 versions)

  • Installed and used enterprise modules, if any: No

  • JVM version and operating system version: 1.8, Centos7.3

  • Elasticsearch log messages on debug level

  • Other installed Elasticsearch or Kibana plugins, if any

xpack.spaces.enabled: false

Hi,
I am seeing something strange. I can use curl with basic auth as any configured SG user (admin/kibanaserver for example) to do a GET on /api/saved_object kibana endpoint, and that works. I can also successfully use certs with curl to do a GET on any elasticsearch endpoint. So it appears that the SG config is working -(both basic auth and clientcert authentication are successfull … depending on the path). However, if I try to use the same cert that was used in successfully accessing elasticsearch to try to connect to kibana and do a GET on /api/saved_objects, curl responds with a:

{“message”:“Session expired”,“redirectTo”:“login”}

It appears to be a bug in the way impersonation works (or not) between the two paths and something needs to be fixed in the search-guard kibana plugin. On the other hand, I would be ecstatic to hear that I configured something wrong…

Insights?

Lars

I'm afraid that's not possible.

Pls. have a look here https://docs.search-guard.com/latest/kibana-authentication-types to see which ways of authenticating users we support.

···

Am 12.01.2019 um 09:33 schrieb lfredriksen@mapr.com:

When asking questions, please provide the following information:

* Search Guard and Elasticsearch version: SG 6.5.3-24/6.5.3-17(kibana), ES@6.5.3 / (same for 6.2.3 versions)
* Installed and used enterprise modules, if any: No
* JVM version and operating system version: 1.8, Centos7.3
* Elasticsearch log messages on debug level
* Other installed Elasticsearch or Kibana plugins, if any
xpack.spaces.enabled: false

Hi,
I am seeing something strange. I can use curl with basic auth as any configured SG user (admin/kibanaserver for example) to do a GET on /api/saved_object kibana endpoint, and that works. I can also successfully use certs with curl to do a GET on any elasticsearch endpoint. So it appears that the SG config is working -(both basic auth and clientcert authentication are successfull .. depending on the path). However, if I try to use the same cert that was used in successfully accessing elasticsearch to try to connect to kibana and do a GET on /api/saved_objects, curl responds with a:
{"message":"Session expired","redirectTo":"login"}

It appears to be a bug in the way impersonation works (or not) between the two paths and something needs to be fixed in the search-guard kibana plugin. On the other hand, I would be ecstatic to hear that I configured something wrong..

Insights?

Lars

--
You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" 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/8dcdc70b-d1ea-4bb5-8d75-03cf3cd1ee5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Thanks for the prompt reply. I had seen the documentation you pointed to and was just hoping the lack of mention of client certs for the kibana users were just a simple oversight since both the server side of kibana and obviously the elastisearch side supports it.

Any plans to support it?

Thanks,
Lars

···

On Saturday, January 12, 2019 at 1:06:40 PM UTC-6, Search Guard wrote:

I’m afraid that’s not possible.

Pls. have a look here https://docs.search-guard.com/latest/kibana-authentication-types to see which ways of authenticating users we support.

Am 12.01.2019 um 09:33 schrieb lfred...@mapr.com:

When asking questions, please provide the following information:

  • Search Guard and Elasticsearch version: SG 6.5.3-24/6.5.3-17(kibana), ES@6.5.3 / (same for 6.2.3 versions)
  • Installed and used enterprise modules, if any: No
  • JVM version and operating system version: 1.8, Centos7.3
  • Elasticsearch log messages on debug level
  • Other installed Elasticsearch or Kibana plugins, if any

xpack.spaces.enabled: false

Hi,

I am seeing something strange. I can use curl with basic auth as any configured SG user (admin/kibanaserver for example) to do a GET on /api/saved_object kibana endpoint, and that works. I can also successfully use certs with curl to do a GET on any elasticsearch endpoint. So it appears that the SG config is working -(both basic auth and clientcert authentication are successfull … depending on the path). However, if I try to use the same cert that was used in successfully accessing elasticsearch to try to connect to kibana and do a GET on /api/saved_objects, curl responds with a:

{“message”:“Session expired”,“redirectTo”:“login”}

It appears to be a bug in the way impersonation works (or not) between the two paths and something needs to be fixed in the search-guard kibana plugin. On the other hand, I would be ecstatic to hear that I configured something wrong…

Insights?

Lars


You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” 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/8dcdc70b-d1ea-4bb5-8d75-03cf3cd1ee5c%40googlegroups.com.

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

It's technically not possible due to the archtitecture of Kibana

···

Am 12.01.2019 um 20:34 schrieb lfredriksen@mapr.com:

Thanks for the prompt reply. I had seen the documentation you pointed to and was just hoping the lack of mention of client certs for the kibana users were just a simple oversight since both the server side of kibana and obviously the elastisearch side supports it.

Any plans to support it?

Thanks,
Lars

On Saturday, January 12, 2019 at 1:06:40 PM UTC-6, Search Guard wrote:
I'm afraid that's not possible.

Pls. have a look here https://docs.search-guard.com/latest/kibana-authentication-types to see which ways of authenticating users we support.

> Am 12.01.2019 um 09:33 schrieb lfred...@mapr.com:
>
> When asking questions, please provide the following information:
>
> * Search Guard and Elasticsearch version: SG 6.5.3-24/6.5.3-17(kibana), ES@6.5.3 / (same for 6.2.3 versions)
> * Installed and used enterprise modules, if any: No
> * JVM version and operating system version: 1.8, Centos7.3
> * Elasticsearch log messages on debug level
> * Other installed Elasticsearch or Kibana plugins, if any
> xpack.spaces.enabled: false
>
> Hi,
> I am seeing something strange. I can use curl with basic auth as any configured SG user (admin/kibanaserver for example) to do a GET on /api/saved_object kibana endpoint, and that works. I can also successfully use certs with curl to do a GET on any elasticsearch endpoint. So it appears that the SG config is working -(both basic auth and clientcert authentication are successfull .. depending on the path). However, if I try to use the same cert that was used in successfully accessing elasticsearch to try to connect to kibana and do a GET on /api/saved_objects, curl responds with a:
> {"message":"Session expired","redirectTo":"login"}
>
> It appears to be a bug in the way impersonation works (or not) between the two paths and something needs to be fixed in the search-guard kibana plugin. On the other hand, I would be ecstatic to hear that I configured something wrong..
>
> Insights?
>
> Lars
>
>
> --
> You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" 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/8dcdc70b-d1ea-4bb5-8d75-03cf3cd1ee5c%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" 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/54661869-3a51-4e73-ab41-c22a075b8715%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.