Configuring Reporting when behind a reverse-proxy

[kobelb]

When Kibana is hosted behind a reverse proxy, the administrator is required to input the proxy's hostname, protocol and port via the respective xpack.reporting.server.* kibana.yml settings. We need this information to generate the URL that we should visit from Reporting's headless browser to generate the necessary reports. Manually requiring users to input this information has been problematic, and mis-configuration is rather common.

There's potential for us to provide the hostname, protocol and port via the job parameters when generating the report, but this opens us up to end-users being able to control the URL that the headless browser visits when generating the report, where they could potentially exploit a browser vulnerability to compromise the server that Kibana is running on.

A compromise between these two approaches would be to provide the hostname, protocol and port via the job parameters which are then validated via a white-list or the existing configuration options and throw an informative error message if these values don't match with the specific settings that the user must change.

[tsullivan]

When Kibana is hosted behind a reverse proxy, the administrator is required to input the proxy's hostname

@kobelb are you sure it's required, or is it only required in the case where the proxy provides request rewriting behavior?

I had just filed #26670 and I saw this issue

[tsullivan]

@kobelb is this still a valid issue since per #26670, the administrator is not always required to put in the proxy settings?

[kobelb]

Feel free to close this issue if you feel it's wise to go the course of no longer recommending all users with Kibana hosted behind a reverse-proxy configure these settings to make Reporting go through the same reverse proxy. For us to without a doubt ensure that Reporting works when Kibana is behind a reverse-proxy, we should also be going through the reverse proxy.

[tsullivan]

I can confirm it is possible to run Kibana behind a reverse proxy and use reporting without touching the xpack.reporting.kibanaServer.* settings.

When I first tried it (Kibana 7.0.0-snapshot, docker image), jobs were failing and I could tell by the awesome new logging that I was hitting the /login route. Looking at more debugging output, I could see:

kibana_1               | {"type":"log","@timestamp":"2018-12-07T22:06:53Z","tags":["reporting","browser-driver","chromium-driver-factory","headless-chromium-driver","debug"],"pid":1,"message":"opening url http://0:5601/app/kibana#/dashboard/1be9acd0-f8b8-11e8-8605-0f144864cbad?_g=()&_a=(description%3A''%2Cfilters%3A!()%2CfullScreenMode%3A!f%2Coptions%3A(darkTheme%3A!f%2ChidePanelTitles%3A!f%2CuseMargins%3A!t)%2Cpanels%3A!((embeddableConfig%3A()%2CgridData%3A(h%3A15%2Ci%3A'1'%2Cw%3A24%2Cx%3A0%2Cy%3A0)%2Cid%3A'09198b20-f8b8-11e8-8605-0f144864cbad'%2CpanelIndex%3A'1'%2Ctype%3Avisualization%2Cversion%3A'7.0.0'))%2Cquery%3A(language%3Alucene%2Cquery%3A'')%2CtimeRestore%3A!f%2Ctitle%3A'Baby%20Names'%2CviewMode%3Aview)&forceNow=2018-12-07T22%3A06%3A52.470Z"}
kibana_1               | {"type":"log","@timestamp":"2018-12-07T22:06:53Z","tags":["reporting","browser-driver","chromium-driver-factory","headless-chromium-driver","debug"],"pid":1,"message":"No custom headers for http://0.0.0.0:5601/app/kibana"}

I set the following environment variable for the Kibana service:

 "SERVER_HOST=0.0.0.0"

That gets Reporting to send the authentication headers to the Kibana host properly.

[tsullivan]

@kobelb

For us to without a doubt ensure that Reporting works when Kibana is behind a reverse-proxy, we should also be going through the reverse proxy.

In this comment, did you mean we should work with reverse proxy in a dev environment?

[kobelb]

I was trying to say that there are certain configurations of Kibana behind a reverse-proxy that require us to go through the reverse proxy for Reporting to work properly, so the safest definitive way to recommend that Reporting is configured in these scenarios is for us to set the xpack.reporting.kibanaServer.* settings. Otherwise, we'll likely want to enumerate the potential configurations that require this.

[elasticmachine]

Pinging @elastic/kibana-reporting-services (Team:Reporting Services)

[tsullivan]

I think this is ready to close

There's potential for us to provide the hostname, protocol and port via the job parameters when generating the report,

I don't think this would work in all proxy and network configurations. The xpack_reporting_kibanaserver_hostname could be an internal name of the proxy.

The way we've been tackling issues like this is to run self-checks at server startup, and log a descriptive warning or error if we find any problems. See for example: #53975

I've thought about having a server host check that actually would use Chromium to resolve the address, but it wasn't added because my implementation was a bad race-condition problem with the the legacy platform.