Help for Grafana configuration

Hi,

I would like to test grafana server who gives the possibility to add elasticsearch as data source.

Now that I have elasticsearch running with searchguard, i’m lost with the TLS configuration. Which one should I choose to allow grafana to access elasticsearch ?

They ask :

-client-certificate

  • client -key
  • client CA (optionnal)

Here is my config in elasticsearch.yml

searchguard.ssl.transport.keystore_type: JKS
searchguard.ssl.transport.keystore_filepath: CN=localhost-keystore.jks
searchguard.ssl.transport.keystore_password: xxx
searchguard.ssl.transport.truststore_type: JKS
searchguard.ssl.transport.truststore_filepath : truststore.jks
searchguard.ssl.transport.truststore_password : xxx

searchguard.ssl.http.enabled: true
searchguard.ssl.http.keystore_type : JKS
searchguard.ssl.http.keystore_filepath : CN=localhost-keystore.jks
searchguard.ssl.http.keystore_password: xxx
searchguard.ssl.http.truststore_type: JKS
searchguard.ssl.http.truststore_filepath : truststore.jks
searchguard.ssl.http.truststore_password : xxx

searchguard.authcz.admin_dn:

  • CN=sgadmin

``

I tried to use `

  • CN=localhost certificate (even if i don’t find the key for that one)
  • CN=sgadmin certificate (with the appropriate key)
    And a lot of others certificate/key pairs that i found in my search-guard certificate folders but doesn’t seems appropriate.

Nothing works. Below is the configuration requested for grafana for your information.

Any help on this ?

`

Grafana does not need to present a certificate to elasticsearch/searchguard (unless you want to leverage client based authentication).
If you want to use client based authentication you must configure this in sg_config_yml and you need to create a client certificate (for example the spock certificate)
If not just use http basic auth.

···

Am 04.10.2017 um 16:22 schrieb Charlotte Dupont <charlotte.dupont@eglobalmark.com>:

Hi,

I would like to test grafana server who gives the possibility to add elasticsearch as data source.

Now that I have elasticsearch running with searchguard, i'm lost with the TLS configuration. Which one should I choose to allow grafana to access elasticsearch ?

They ask :

-client-certificate
- client -key
- client CA (optionnal)

Here is my config in elasticsearch.yml

searchguard.ssl.transport.keystore_type: JKS
searchguard.ssl.transport.keystore_filepath: CN=localhost-keystore.jks
searchguard.ssl.transport.keystore_password: xxx
searchguard.ssl.transport.truststore_type: JKS
searchguard.ssl.transport.truststore_filepath : truststore.jks
searchguard.ssl.transport.truststore_password : xxx

searchguard.ssl.http.enabled: true
searchguard.ssl.http.keystore_type : JKS
searchguard.ssl.http.keystore_filepath : CN=localhost-keystore.jks
searchguard.ssl.http.keystore_password: xxx
searchguard.ssl.http.truststore_type: JKS
searchguard.ssl.http.truststore_filepath : truststore.jks
searchguard.ssl.http.truststore_password : xxx

searchguard.authcz.admin_dn:
  - CN=sgadmin

I tried to use
- CN=localhost certificate (even if i don't find the key for that one)
- CN=sgadmin certificate (with the appropriate key)
And a lot of others certificate/key pairs that i found in my search-guard certificate folders but doesn't seems appropriate.

Nothing works. Below is the configuration requested for grafana for your information.

Any help on this ?

<Auto Generated Inline Image 1.png>

--
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/01c81ff6-f045-49b7-a8e2-d2ecd78fa868%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
<Auto Generated Inline Image 1.png>

Thanks for your reply.
I tried to use only the http basic auth, but with my admin user and password, it is still not working.
Is it a all_access user from the sg_internal_user.yml that i should use ?

Maybe the problem is somewhere else in my grafana config…

Hi,

We’re successfully using Grafana with Searchguard.
However, we chose the option to use our SSO based on XFF.
Thus we have an apache reverse proxy configured to forward the user header.
Both ES and Grafana use the same SSO (CAS).

The grafana datasource is pointing to that proxy and “with credentials” is ticked to forward the headers.

Cheers

If you are using the demo configuration files that ship with Search Guard, then

  • HTTP Basic Authentication is enabled by default

  • The user admin with password admin has access to all indices and all document types

So, please try to to use the default configs first, and configure Grafana to use Basic Auth and the user admin/admin. If this works, then you can start to limit access as required.

We test Search Guard with Grafana, and can verify that the two products are compatible.

···

On Monday, October 9, 2017 at 2:55:22 PM UTC+2, Fabien Wernli wrote:

Hi,

We’re successfully using Grafana with Searchguard.
However, we chose the option to use our SSO based on XFF.
Thus we have an apache reverse proxy configured to forward the user header.
Both ES and Grafana use the same SSO (CAS).

The grafana datasource is pointing to that proxy and “with credentials” is ticked to forward the headers.

Cheers

Hi, I’m not using a default config file, and I was wondering what credential to use. For example for Kibana to log in there is specific user and password. For logstash input, there is also a specific user. So I was wondering if maybe i need to create a specific user for grafana to be able to connect.

Anyway I tried basic authentification with my admin user/password. I have a refused connection.
Here is the elasticsearch logs when grafana tries to connect :

[2017-10-17T15:37:18,242][WARN ][c.f.s.h.SearchGuardHttpServerTransport] [cFJgxmD] caught exception while handling client http traffic, closing connection [id: 0x1fe6e957, L:0.0.0.0/0.0.0.0:9200 ! R:/{grafanahost}:41638]
io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: no cipher suites in common
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:442) ~[netty-codec-4.1.7.Final.jar:4.1.7.Final]
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248) ~[netty-codec-4.1.7.Final.jar:4.1.7.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:363) [netty-transport-4.1.7.Final.jar:4.1.7.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:349) [netty-transport-4.1.7.Final.jar:4.1.7.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:341) [netty-transport-4.1.7.Final.jar:4.1.7.Final]
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334) [netty-transport-4.1.7.Final.jar:4.1.7.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:363) [netty-transport-4.1.7.Final.jar:4.1.7.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:349) [netty-transport-4.1.7.Final.jar:4.1.7.Final]
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926) [netty-transport-4.1.7.Final.jar:4.1.7.Final]
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:129) [netty-transport-4.1.7.Final.jar:4.1.7.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:642) [netty-transport-4.1.7.Final.jar:4.1.7.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeysPlain(NioEventLoop.java:527) [netty-transport-4.1.7.Final.jar:4.1.7.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:481) [netty-transport-4.1.7.Final.jar:4.1.7.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:441) [netty-transport-4.1.7.Final.jar:4.1.7.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858) [netty-common-4.1.7.Final.jar:4.1.7.Final]
at java.lang.Thread.run(Thread.java:745) [?:1.8.0_111]
Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in common
at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1431) ~[?:?]
at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535) ~[?:?]
at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:813) ~[?:?]
at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781) ~[?:?]
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) ~[?:1.8.0_111]
at io.netty.handler.ssl.SslHandler$SslEngineType$2.unwrap(SslHandler.java:218) ~[?:?]
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1028) ~[?:?]
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:950) ~[?:?]
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411) ~[?:?]
… 15 more
Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in common
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) ~[?:?]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666) ~[?:?]
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:304) ~[?:?]
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:292) ~[?:?]
at sun.security.ssl.ServerHandshaker.chooseCipherSuite(ServerHandshaker.java:1035) ~[?:?]
at sun.security.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:738) ~[?:?]
at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:221) ~[?:?]
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979) ~[?:?]
at sun.security.ssl.Handshaker$1.run(Handshaker.java:919) ~[?:?]
at sun.security.ssl.Handshaker$1.run(Handshaker.java:916) ~[?:?]
at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_111]
at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1369) ~[?:?]
at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1167) ~[?:?]
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1080) ~[?:?]
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:950) ~[?:?]
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411) ~[?:?]
… 15 more

``

···

On Tuesday, October 10, 2017 at 2:34:36 PM UTC+2, Jochen Kressin wrote:

If you are using the demo configuration files that ship with Search Guard, then

  • HTTP Basic Authentication is enabled by default
  • The user admin with password admin has access to all indices and all document types

So, please try to to use the default configs first, and configure Grafana to use Basic Auth and the user admin/admin. If this works, then you can start to limit access as required.

We test Search Guard with Grafana, and can verify that the two products are compatible.

On Monday, October 9, 2017 at 2:55:22 PM UTC+2, Fabien Wernli wrote:

Hi,

We’re successfully using Grafana with Searchguard.
However, we chose the option to use our SSO based on XFF.
Thus we have an apache reverse proxy configured to forward the user header.
Both ES and Grafana use the same SSO (CAS).

The grafana datasource is pointing to that proxy and “with credentials” is ticked to forward the headers.

Cheers

Ok, this sheds some light on the problem:

Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in common

    at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) ~[?:?]

    at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666) ~[?:?]

    at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:304) ~[?:?]

    at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:292) ~[?:?]

    at sun.security.ssl.ServerHandshaker.chooseCipherSuite(ServerHandshaker.java:1035) ~[?:?]

This means that your browser and the server do not have any TLS ciper suites in common, so no TLS session can be established. This is not a Search Guard issue per se, so:

  • What JVM do you use (vendor and version)

  • What browser do you use?

Maybe an OpenJDK / Chrome combination?

···

On Tuesday, October 17, 2017 at 5:45:15 PM UTC+2, Charlotte Dupont wrote:

Hi, I’m not using a default config file, and I was wondering what credential to use. For example for Kibana to log in there is specific user and password. For logstash input, there is also a specific user. So I was wondering if maybe i need to create a specific user for grafana to be able to connect.

Anyway I tried basic authentification with my admin user/password. I have a refused connection.
Here is the elasticsearch logs when grafana tries to connect :

[2017-10-17T15:37:18,242][WARN ][c.f.s.h.SearchGuardHttpServerTransport] [cFJgxmD] caught exception while handling client http traffic, closing connection [id: 0x1fe6e957, L:0.0.0.0/0.0.0.0:9200 ! R:/{grafanahost}:41638]
io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: no cipher suites in common
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:442) ~[netty-codec-4.1.7.Final.jar:4.1.7.Final]
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248) ~[netty-codec-4.1.7.Final.jar:4.1.7.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:363) [netty-transport-4.1.7.Final.jar:4.1.7.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:349) [netty-transport-4.1.7.Final.jar:4.1.7.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:341) [netty-transport-4.1.7.Final.jar:4.1.7.Final]
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334) [netty-transport-4.1.7.Final.jar:4.1.7.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:363) [netty-transport-4.1.7.Final.jar:4.1.7.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:349) [netty-transport-4.1.7.Final.jar:4.1.7.Final]
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926) [netty-transport-4.1.7.Final.jar:4.1.7.Final]
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:129) [netty-transport-4.1.7.Final.jar:4.1.7.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:642) [netty-transport-4.1.7.Final.jar:4.1.7.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeysPlain(NioEventLoop.java:527) [netty-transport-4.1.7.Final.jar:4.1.7.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:481) [netty-transport-4.1.7.Final.jar:4.1.7.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:441) [netty-transport-4.1.7.Final.jar:4.1.7.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858) [netty-common-4.1.7.Final.jar:4.1.7.Final]
at java.lang.Thread.run(Thread.java:745) [?:1.8.0_111]
Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in common
at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1431) ~[?:?]
at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535) ~[?:?]
at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:813) ~[?:?]
at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781) ~[?:?]
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) ~[?:1.8.0_111]
at io.netty.handler.ssl.SslHandler$SslEngineType$2.unwrap(SslHandler.java:218) ~[?:?]
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1028) ~[?:?]
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:950) ~[?:?]
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411) ~[?:?]
… 15 more
Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in common
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) ~[?:?]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666) ~[?:?]
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:304) ~[?:?]
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:292) ~[?:?]
at sun.security.ssl.ServerHandshaker.chooseCipherSuite(ServerHandshaker.java:1035) ~[?:?]
at sun.security.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:738) ~[?:?]
at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:221) ~[?:?]
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979) ~[?:?]
at sun.security.ssl.Handshaker$1.run(Handshaker.java:919) ~[?:?]
at sun.security.ssl.Handshaker$1.run(Handshaker.java:916) ~[?:?]
at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_111]
at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1369) ~[?:?]
at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1167) ~[?:?]
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1080) ~[?:?]
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:950) ~[?:?]
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411) ~[?:?]
… 15 more

``

On Tuesday, October 10, 2017 at 2:34:36 PM UTC+2, Jochen Kressin wrote:

If you are using the demo configuration files that ship with Search Guard, then

  • HTTP Basic Authentication is enabled by default
  • The user admin with password admin has access to all indices and all document types

So, please try to to use the default configs first, and configure Grafana to use Basic Auth and the user admin/admin. If this works, then you can start to limit access as required.

We test Search Guard with Grafana, and can verify that the two products are compatible.

On Monday, October 9, 2017 at 2:55:22 PM UTC+2, Fabien Wernli wrote:

Hi,

We’re successfully using Grafana with Searchguard.
However, we chose the option to use our SSO based on XFF.
Thus we have an apache reverse proxy configured to forward the user header.
Both ES and Grafana use the same SSO (CAS).

The grafana datasource is pointing to that proxy and “with credentials” is ticked to forward the headers.

Cheers

Hi,

I use Mozilla Firefox, but after your reply i also tried with Chrome with the same result.

This is my java version :
openjdk version “1.8.0_111”
OpenJDK Runtime Environment (build 1.8.0_111-b15)
OpenJDK 64-Bit Server VM (build 25.111-b15, mixed mode)

This is not actually a Search Guard issue, but is connected with OpenJDK, which is not officially supported. The error is due to the fact none of the cipher suites shipped by default with OpenJDK is supported by modern browsers. This is what this error message is saying:

Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in common

So either switch to OracleJDK, or install an additional security provider like BouncyCastle that supports current ciphers.

···

On Wednesday, October 18, 2017 at 8:48:05 AM UTC+2, Charlotte Dupont wrote:

Hi,

I use Mozilla Firefox, but after your reply i also tried with Chrome with the same result.

This is my java version :
openjdk version “1.8.0_111”
OpenJDK Runtime Environment (build 1.8.0_111-b15)
OpenJDK 64-Bit Server VM (build 25.111-b15, mixed mode)

I switched to Oracle JDK, restarted ELK cluster and it works perfectly now.

Thanks a lot !