Elasticsearch preserveHost setting

[kobelb]

There's currently a elasticsearch.preserveHost setting that according to the docs when it's set to false it should forward the host header that's sent to Kibana to Elasticsearch. However, this setting doesn't appear to be used and according to this issue we intended to remove support for it in 5.0.

We have some customers requesting this functionality so Elasticsearch is able to audit the actual clients that are making requests, and we'd need this functionality to be able to do so.

/cc @epixa @elastic/kibana-operations do you all have any additional history regarding this setting that would prevent us from re-introducing it?

[epixa]

@kobelb I haven't tested this for the host header specifically, but I'm pretty sure this can be done by whitelisting the host header in elasticsearch.requestHeadersWhitelist.

[kobelb]

@epixa if I understand what we were doing in https://github.com/elastic/kibana/pull/8105/files correctly, we used to hard-code the host header to the elasticsearch URL because not doing so "broke the proxy" is this no longer a concern?

[epixa]

@kobelb The host header is how a remote server determines where to route a request to internally, so if you preserve the host header from a client (the browser) through a proxy (the kibana server), the remote server may get a host value that it doesn't recognize. This doesn't mean it will always break, but it will break under certain combinations of conditions.

If you're looking for a universal way where we can always pass the origin host through to elasticsearch without any risk of impacting the routing on that server, then passing through the host header verbatim is not viable.

When the PR you linked was merged, the elasticsearch.requestHeadersWhitelist feature didn't exist and all headers were blindly passed to elasticsearch for all requests except for the host header. That's why the preserveHost configuration needed to exist at that time, so users could choose to pass the host header if they so desired.

Now that headers are only passed if they are explicitly configured via elasticsearch.requestHeadersWhitelist, you should instead be able to use that configuration to whitelist the host header.

We should remove the preserveHost configuration entirely by deprecating it in 6.x and deleting it in 7.0.

It's also possible that this preserveHost stuff is just a distraction from what you actually want to accomplish here, and that a new feature entirely is in order to support the use case you're after.

[kobelb]

It's also possible that this preserveHost stuff is just a distraction from what you actually want to accomplish here, and that a new feature entirely is in order to support the use case you're after.

Most likely, just trying to get the history on the setting.

[kobelb]

It seems like we could either forward the x-forwarded-host header that is sent to Kibana, or add it based on the host header when proxying the requests to Elasticseach to emulate what other "proxies" are doing.

[epixa]

That sounds like the right way to implement the behavior you're looking for. Though we may want to use the forwarded standard header instead.

[kobelb]

I definitely think we should mark the elasticsearch.preserveHost setting as deprecated and warn the user if they're setting it, but it hasn't worked for a while, so it'd be good to remove it from the docs for at least 6.0+

I'm gonna split this issue into multiple, one for fixing the existing docs/deprecations and another for fulfilling the actual customers request, as I conflated the two and after talking with @jkakavas just forwarding the Host isn't going to give them what they were asking for.