* Add a note that the http_ca.crt certificate that is generated and
stored in config/certs can be used to configure any client to trust
the certificate that elasticsearch uses for TLS on the HTTP layer
* Add a note that the elasticsearch-create-enrollment-token CLI
tool can only be used with auto-configured TLS settings.
Add a --url option for elasticsearch-reset-password and
elasticsearch-create-enrollment-token CLI Tools ( and any tools
that would extend BaseRunAsSuperuserCommand ).
The tools use CommandLineHttpClient internally, which tries its
best to deduce the URL of the local node based on the configuration
but there are certain cases where it either fails or returns an
unwanted result. Concretely:
- CommandLineHttpClient#getDefaultURL will always return a URL with
the port set to 9200, unless otherwise explicitly set in the
configuration. When running multiple nodes on the same host,
subsequent nodes get sequential port numbers after 9200 by default
and this means that the CLI tool will always connect the first of
n nodes in a given host. Since these tools depend on a file realm
local user, requests to other nodes would fail
- When an ES node binds and listens to many addresses, there can
be the case that not all of the IP addresses are added as SANs in
the certificate that is used for TLS on the HTTP layer.
CommandLineHttpClient#getDefaultURL will pick an address based on
a preference order but that address might not be in the SANs and
thus all requests to the node would fail due to failed hostname
verification.
Manually setting `--url` to an appropriate value allows users to
overcome these edge cases.
This change introduces a CLI tool that can be used to create
enrollment tokens. It doesn't require credentials, but simply
write access to the local filesystem of a node. It uses an
auto-generated user in the file-realm with superuser role.
For this purpose, this change also introduces a base class for a
CLI tool that can be used by any CLI tool needs to perform actions
against an ES node as a superuser without requiring credentials
from the user. It is worth noting that this doesn't change our
existing thread model, because already an actor with write access
to the fs of an ES node, can become superuser (again, by
adding a superuser to the file realm, albeit manually).
Co-authored-by: Adam Locke <adam.locke@elastic.co>
