Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No longer setting certs and keys for proxied calls to Elasticsearch #17804

Merged
merged 2 commits into from
May 3, 2018

Conversation

kobelb
Copy link
Contributor

@kobelb kobelb commented Apr 19, 2018

When proxying requests for end-users (callWithRequest, elasticsearch Proxy, etc) through the kibana server we shouldn't be including the cert/key when establishing this connection and we should only be using the certificate authority.

"Release Note: Resolved issue with using PKI to authenticate the internal server user against Elasticsearch when X-Pack Security is disabled or the realms in Elasticsearch are configured with PKI taking precedence to basic authentication"

@kobelb kobelb requested review from epixa and legrego April 19, 2018 19:13
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@legrego
Copy link
Member

legrego commented Apr 20, 2018

If I'm understanding this change correctly, one of the effects is that Elasticsearch's xpack.security.http.ssl.client_authentication config option must not be set to required if Kibana is connected to the cluster.

Is this intended behavior? If so (and if I'm not missing something), it might be worthwhile to update our documentation to reflect that.

In my testing, I could no longer get Kibana to function properly with client auth required on the ES side.

Here's my console output when running with X-Pack:

Elasticsearch ERROR: 2018-04-20T13:55:32Z
  Error: Request error, retrying
  GET https://127.0.0.1:9200/_xpack/security/_authenticate => write EPROTO 140735791256448:error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate:../deps/openssl/openssl/ssl/s3_pkt.c:1498:SSL alert number 42
  140735791256448:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:../deps/openssl/openssl/ssl/s3_pkt.c:659:

      at Log.error (/Users/larry/repos/kibana/node_modules/elasticsearch/src/lib/log.js:225:56)
      at checkRespForFailure (/Users/larry/repos/kibana/node_modules/elasticsearch/src/lib/transport.js:258:18)
      at HttpConnector.<anonymous> (/Users/larry/repos/kibana/node_modules/elasticsearch/src/lib/connectors/http.js:157:7)
      at ClientRequest.bound (/Users/larry/repos/kibana/node_modules/elasticsearch/node_modules/lodash/dist/lodash.js:729:21)
      at ClientRequest.emit (events.js:180:13)
      at ClientRequest.emit (domain.js:422:20)
      at TLSSocket.socketErrorListener (_http_client.js:395:9)
      at TLSSocket.emit (events.js:180:13)
      at TLSSocket.emit (domain.js:422:20)
      at onwriteError (_stream_writable.js:431:12)
      at onwrite (_stream_writable.js:453:5)
      at _destroy (internal/streams/destroy.js:39:7)
      at TLSSocket.Socket._destroy (net.js:548:3)
      at TLSSocket.destroy (internal/streams/destroy.js:32:8)
      at WriteWrap.afterWrite (net.js:846:10)

Elasticsearch WARNING: 2018-04-20T13:55:32Z
  Unable to revive connection: https://127.0.0.1:9200/

Elasticsearch WARNING: 2018-04-20T13:55:32Z
  No living connections

  log   [13:55:32.278] [info][authentication] Authentication attempt failed: No Living connections
 error  [13:55:32.204]  Error: No Living connections
    at sendReqWithConnection (/Users/larry/repos/kibana/node_modules/elasticsearch/src/lib/transport.js:225:15)
    at next (/Users/larry/repos/kibana/node_modules/elasticsearch/src/lib/connection_pool.js:213:7)
    at process._tickCallback (internal/process/next_tick.js:176:11)

Here's my console output when running without X-Pack:

log   [13:58:05.163] [error][admin][elasticsearch] Request error, retrying
GET https://127.0.0.1:9200/.awesome/doc/config%3A7.0.0-alpha1 => write EPROTO 140735791256448:error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate:../deps/openssl/openssl/ssl/s3_pkt.c:1498:SSL alert number 42
140735791256448:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:../deps/openssl/openssl/ssl/s3_pkt.c:659:

  log   [13:58:05.174] [warning][admin][elasticsearch] Unable to revive connection: https://127.0.0.1:9200/
  log   [13:58:05.174] [warning][admin][elasticsearch] No living connections
  log   [13:58:07.696] [warning][admin][elasticsearch] Unable to revive connection: https://127.0.0.1:9200/
  log   [13:58:07.697] [warning][admin][elasticsearch] No living connections

@kobelb
Copy link
Contributor Author

kobelb commented Apr 20, 2018

That's correct, we can no longer run Elasticsearch requiring certificates because they aren't present for the requests that we proxy through Kibana for end-users, they must set it to "optional". This limitation will be noted in the release notes.

@kobelb kobelb requested review from jbudz and removed request for epixa April 25, 2018 13:13
@jbudz
Copy link
Member

jbudz commented Apr 30, 2018

Reviewing now, sorry for the delay. @kobelb when you get a chance can you rebase so we get a CI run with the x-pack changes?

@jbudz
Copy link
Member

jbudz commented Apr 30, 2018

Should these settings be removed from https://www.elastic.co/guide/en/kibana/current/settings.html?

@kobelb
Copy link
Contributor Author

kobelb commented Apr 30, 2018

Should these settings be removed from https://www.elastic.co/guide/en/kibana/current/settings.html?

We still want those settings, and the cert/key is used when handling connections from the Kibana server itself to ES (that aren't proxied end-user requests).

Copy link
Member

@legrego legrego left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for clarifying @kobelb -- LGTM once we go green!

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants