Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

elastic user password reset CLI tool #70113

Closed
jkakavas opened this issue Mar 8, 2021 · 5 comments · Fixed by #74892
Closed

elastic user password reset CLI tool #70113

jkakavas opened this issue Mar 8, 2021 · 5 comments · Fixed by #74892
Labels
>enhancement :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) Team:Security Meta label for security team

Comments

@jkakavas
Copy link
Member

jkakavas commented Mar 8, 2021

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 ) : ✔️
@jkakavas jkakavas added >enhancement :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) labels Mar 8, 2021
@elasticmachine elasticmachine added the Team:Security Meta label for security team label Mar 8, 2021
@elasticmachine
Copy link
Collaborator

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

@bytebilly
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Contributor

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
Copy link
Member Author

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.

jkakavas added a commit to jkakavas/elasticsearch that referenced this issue Jul 5, 2021
This change introduces a new CLI tool that allows users to reset
the password for the elastic user, setting it to a user defined
or an auto-generated value.

Resolves: elastic#70113
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>enhancement :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) Team:Security Meta label for security team
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants