elastic user password reset CLI tool

[jkakavas]

It would be beneficial for our users to offer a simple solution for resetting the password of the elastic built-in user.

Requirements

• Easy to use
• Should be generally available
• Allow to set the password to a specific value of automatically generate one
• Need not cover other built-in users, as access to elastic credentials would allow to set the password of any other built-in (or otherwise) user, via the change password API
• Should not change our existing threat model
• Should not depend on external services or personal information ( email based flows etc )

Suggested Solution

We can offer a CLI tool for this purpose. The tool can depend on the file realm and codify the suggested approach we have even now for these kinds of situations where users have lost the password for the elastic user. The flow can be similar to:

1. User runs bin/elasticsearch-tool-name, optionally specifying the requested password value
2. The CLI tool verifies that the file realm is enabled, generates an entry for a file realm temp user with a role of superuser and adds that to the file realm.
3. CLI tool uses the newly created user credentials to query the ES cluster and verify that it's health ( and possibly some more nuanced tests around the security index availability/state )
4. CLI tool calls the change password API and sets the password of the elastic user to the requested value
5. CLI tool deletes the temp user from the file realm and verifies its deletion
6. CLI tool exits.

Requirements satisfied

• Easy to use ✔️
• Should be generally available: 👍 👎 Currently file realm is enabled by default but disabled implicitly when other realms are explicitly defined. We are deprecating and changing this behavior for 8.0.0 though, which means that we can expect the file realm to be generally available in the most cases this tool is used.
• Allow to set the password to a specific value of automatically generate one: ✔️
• Need not cover other built-in users, as access to elastic credentials would allow to set the password of any other built-in (or otherwise) user, via the change password API: ✔️
• Should not change our existing threat model : ✔️ ( Users with write access to the elasticsearch config directory can already use the same process to reset the password, albeit manually )
• Should not depend on external services or personal information ( email based flows etc ) : ✔️

[elasticmachine]

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

[bytebilly]

I like the proposal!

Should it check and use the bootstrap password if not already used? It could be a good unified way to set up the elastic password in scenarios where it is not set yet.

The file realm approach requires that the user running the tool has write access to ES_PATH_CONF, so we should call it out somewhere.

[jkakavas]

Should it check and use the bootstrap password if not already used? It could be a good unified way to set up the elastic password in scenarios where it is not set yet.

What would you see as the benefit that would justify this added complexity @bytebilly? The suggested approach would work fine whether or not the bootstrap password is already used / the elastic password has been set. It shouldn't matter to the user what the underlying technical implementation actually is so I'm not sure what you mean with "unified way" in this case.

The file realm approach requires that the user running the tool has write access to ES_PATH_CONF, so we should call it out somewhere.

Agreed! I mentioned that above in

Should not change our existing threat model : heavy_check_mark ( Users with write access to the elasticsearch config directory can already use the same process to reset the password, albeit manually )

and we'll make sure this is called out in the docs and a helpful message is thrown if this is not the case in runtime

[bytebilly]

What would you see as the benefit that would justify this added complexity @bytebilly? The suggested approach would work fine whether or not the bootstrap password is already used / the elastic password has been set. It shouldn't matter to the user what the underlying technical implementation actually is so I'm not sure what you mean with "unified way" in this case.

Good point. It would work even in cases that the file realm is disabled, but use cases are probably very limited. No need to add complexity.

and we'll make sure this is called out in the docs and a helpful message is thrown if this is not the case in runtime

Oh yes that's what I was meaning, making it clear to the final user

[jkakavas]

It would work even in cases that the file realm is disabled

Aha, now I got you, that's a valid point. As you mention too, this would only cover the use case where the file realm is disabled and the elastic password hasn't already be set via some means. Given that a) the file realm can be enabled (albeit with a node restart required ), b) we are moving towards having the elastic password set by default, c) the file realm always being enabled unless explicitly disabled , I don't think it justifies the effort to cater for that use case.