Set elastic password from stored hash for packaged installations

[jkakavas]

During packaged installations we will be generating and storing a new setting, named autoconfiguration.password_hash in the elasticsearch.keystore. This will be the -to be- password of the elastic user and its value in the keystore will be salted and hashed using the default hashing algorithm of elasticsearch.

We should

• Detect that there is an autoconfiguration.password_hash setting in the keystore
• Create the document for the elastic built-in user in the security index and set its password to the value it read from autoconfiguration.password_hash
• Allow the users to authenticate locally to the node with the actual password that is hashed and stored in autoconfiguration.password_hash even before the password is "promoted" to the security index.
• Strive to have a deterministic behavior that is as simple as possible and easy to describe/argue about. i.e. we should
  • try to prevent race conditions from different nodes attempting to set the password in the security index
  • ensure that once a successful authentication happens with a given password, this password will not change without explicit user interaction.
• not override a user added password ( i.e. on restarts )

Out of scope / handled in other work items

• We can assume the password is already generated and hashed/stored in the keystore

[elasticmachine]

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

[BigPandaToo]

Moving discussion from this draft here...

@jkakavas

what should happen if the security index gets deleted ? Would bootstrapping this again to set value be >valuable/surprising/wrong?

I think it may be valuable (if the index was deleted by mistake for example). Also if it was a conscious decision made by a user it would be confusing, because they would expect the old bootstrap password behaviour. How can we determine that the index has been deleted? Should we try to remove the autoconfiguration.password_hash from that node's keystore once we read it to XPackSettings?

@albertzaharovits

Doing it [setting password hash] in the action listener adds a level of ambiguity about when the password hash is actually >going to take effect, i.e. the keystore seed is a valid password before the index is created, and also after the index is created >but before the change password is executed

But as you suggested above we are going to prioritize autoconfiguration.password_hash over keystore seed

@jkakavas

[If we fail to set the password the first time] something else might have created the security index until the second time this >node starts.. We could in theory extend the check to be "security index doesn't exist or the doc for the elastic user doesn't >exist"

What would be that "something"?

[jkakavas]

How can we determine that the index has been deleted?

We are discussing about triggering some code paths when the security index doesn't exist. If it gets deleted, it won't exist and the behavior will be triggered.

Should we try to remove the autoconfiguration.password_hash from that node's keystore once we read it to XPackSettings?

We can't unfortunately since the file is owned by root and elasticsearch can't write to it.

What would be that "something"?

We trigger the auto-creation of the security index when we need to index a doc into it ( see SecurityIndexManager#prepareIndexIfNeededThenExecute so that something could be the addition of a native user, the creation of an API key etc.

[BigPandaToo]

We are discussing about triggering some code paths when the security index doesn't exist. If it gets deleted, it won't exist >and the behavior will be triggered.

What meant: how we detect that we have already bootstrapped the user and the index was deleted after. I don't think we have a way to detect it, right? But if autoconfiguration.password_hash doesn't exist anymore we won't attempt to do it again.

[BigPandaToo]

We can't unfortunately since the file is owned by root and elasticsearch can't write to it.

((

[BigPandaToo]

so that something could be the addition of a native user, the creation of an API key etc.

Checking for that a doc forelastic doesn't exist is still an option

[jkakavas]

Closed by #78306