[Discuss] Support sending Console requests to different ES clusters

[cjcenizal]

As noted in #8926 (comment), the original manifestation of Console (called Sense) allowed the user to specify the cluster they wanted to send different requests to. This could be useful when diagnosing problems with various clusters.

On the one hand, I can understand the friction of having to set up a Kibana instance on every cluster you want to interact with via Console. I also understand that Console won't be able help if you can't access it because the cluster performance is too degraded. On a conceptual level, if Console is basically a more visual replacement for cURL, then this feature makes a lot of sense.

On the other hand, are there consequences to this? How does this work with security enabled? Does it expose too much information about the cluster to the end user? We opened and addressed #7059 because we didn't want Console to act as an open web proxy.

Monitoring-focused alternative

As noted in #8955, the primary use case for this feature is to manage a production cluster from a monitoring cluster. We could support this and avoid the problems of an open web proxy by adding a setting to kibana.yml that lets you specify the list of URLs you want to be able to manage via Console. This list would populate the dropdown in the Console UI and would also act as a whitelist on the server to make sure requests are only sent to the allowed URLs. This would also address the request brought up in #17473.

[elasticmachine]

Pinging @elastic/es-ui (Team:Elasticsearch UI)

[jloleysens]

Related: #11866

[cjcenizal]

At the present moment, Elastic expects administrators to attach a Kibana instance to no more than one deployment in order to manage and analyze its data. One deployment, >=1 Kibana(s), one Console per Kibana. Closing this until a different approach becomes a priority.