Skip to content

Conversation

@albertzaharovits
Copy link
Contributor

@albertzaharovits albertzaharovits commented Sep 27, 2021

This adds a new way to specify the initial password for the elastic superuser.

This makes use of the new autoconfiguration.password_hash secure setting.
This setting contains the elastic user's password hash, which is used to validate
the elastic's credentials, as long as there are no other alternatives in the
.security index (either if the index does not exist, or if it does not contain
the document for the elastic user).
Still, the interesting thing, which sets this new setting apart from the bootstrap.password
existing one, is that upon a successful validation the hash is written back on the .security index.
Importantly, if the write fails, it results in a 500 or 503 error to the client, rather than a 401.
This has the result that all the other nodes will use the same elastic password from the index
from that point on.

This whole mechanism facilitates fixing the elastic user password, for a cluster, before its
nodes are started.

Replaces #77036
Co-Authored-By: Lyudmila Fokina [email protected]

@BigPandaToo BigPandaToo self-requested a review September 27, 2021 09:40
@albertzaharovits
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/part-2

if (e instanceof ElasticsearchAuthenticationProcessingError) {
return (ElasticsearchAuthenticationProcessingError) e;
}
return createAuthenticationError("error attempting to authenticate request", e, (Object[]) null);
Copy link
Contributor Author

@albertzaharovits albertzaharovits Sep 30, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only raising exceptions with a specific type (ElasticsearchAuthenticationProcessingError) AND while invoking the request processing error handler (and not any other handler), results in 500 or 503; anything else goes to 401 .

protected SecureString getBootstrapPassword() {
return TEST_PASSWORD_SECURE_STRING;
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need this in order to override to not set the bootstrap password.


public ReservedRealm(Environment env, Settings settings, NativeUsersStore nativeUsersStore, AnonymousUser anonymousUser,
SecurityIndexManager securityIndex, ThreadPool threadPool) {
ThreadPool threadPool) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Accounting for if the security index exists is redundant because the native users store does it already.

@albertzaharovits albertzaharovits added >enhancement :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) labels Sep 30, 2021
@albertzaharovits albertzaharovits marked this pull request as ready for review September 30, 2021 16:52
@elasticmachine elasticmachine added the Team:Security Meta label for security team label Sep 30, 2021
@elasticmachine
Copy link
Collaborator

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

Copy link
Contributor

@jkakavas jkakavas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is superb Albert. I like how clean ReservedRealm#doAuthenticate is and the diligence you put into testing. I verified manually too that this does work as advertised ( happy path ) and the test coverage for error cases makes me confident to merge. I'll wait for Lyudmila to share any thoughts are she has spent time on this too and has context from the previous PR, but LGTM from my side

Copy link
Contributor

@jkakavas jkakavas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some testing nits

@albertzaharovits albertzaharovits added the :Security/FIPS Running ES in FIPS 140-2 mode label Oct 5, 2021
@albertzaharovits
Copy link
Contributor Author

@elasticmachine test this please

@albertzaharovits albertzaharovits merged commit cfadab4 into elastic:master Oct 5, 2021
@albertzaharovits albertzaharovits deleted the set-auto-conf-password branch October 5, 2021 08:45
jkakavas added a commit that referenced this pull request Oct 15, 2021
This commit ensures that for packaged installations
we will run the auto-configuration code on installation (but not upgrade) time. 
This is needed because we expect elasticsearch to be run as a service. 
By the time the service runs, the configuration directory is not writable by the
user that runs elasticsearch so we can't  persist configuration and key/certificate
material on runtime. Running auto-configuration on installation time
allows us to print information to the user that they have better chance of seeing 
(barring unattended installations). We don't have the option to show output to the
user when starting the service with systemctl. 

During installation we:
- Generate TLS material, enable security and TLS and persist on disk
- Generate a password for the elastic user and store a hash of this 
in the elasticsearch.keystore. This will be picked up by the node
starting and will be "promoted" to be the cluster wide elastic
password on first startup. (see #78306 )
- We notify the user in the output of the package installation about
whether we succeed and what the password of the elastic user is.
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) :Security/FIPS Running ES in FIPS 140-2 mode Team:Security Meta label for security team v8.0.0-beta1

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants