CLI tools extending BaseRunAsSuperuserCommand should only connect to the local node

[jkakavas]

BaseRunAsSuperuserCommand uses a temporary file realm superuser to execute commands as. Since file realms are node specific, all requests should be executed against the local node from where the CLI runs.

We should not use CommandLineHttpClient#getDefaultURL or adjust it to prefer the local node if/when possible. At a minimum all tools that extend BaseRunAsSuperuserCommand should support a --url parameter that allows the user to override and point to the local node

[elasticmachine]

Pinging @elastic/es-security (Team:Security)

[bytebilly]

This is very helpful in scenarios where the node certificate doesn't have the non-local address, but security is set.
In this case, the node is normally configured with verification_type=certificate, but the tool cannot run properly.

[jkakavas]

The main problems are two I believe:

1. CommandLineHttpClient#getDefaultURL() will always return a url with port set to 9200, unless the port is explicitly set in the configuration. That means that for multiple nodes running on the same host ( which get sequential ports 9200, 9201, etc ) the CLI tool will always attempt to talk to the first node that was spun on the host and got to bind to 9200, even if run from other nodes.

2. In cases where we bind to multiple addresses (either via a keyword like _site_, or _global_ , or binding to 0.0.0.0) CommandLineHttpClient#getDefaultURL() will pick one address to return. The certificate that the host uses might not have all these as SANs so if we pick one that's not in the SAN, the connection will fail.

There are existing workarounds for both:

• For 1. , one can tell the CLI tool where the node is listening by passing a configuration setting such as bin/elasticsearch-create-enrollment-token -s node -Ehttp.port=9201
• For 2. , one can tell the CLI to use another address while constructing the URL by passing i.e. -Ehttp.publish_host=hostname_here

Both of these can be solved by allowing to pass a --url parameter, and this is what I'm planning to address this issue with.