Fix error message when changing the password for a user in the file realm #127621
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… user attempts to update the password for the `elastic` superuser in a cloud deployment. At the heart of the issue is the difference in how the `elastic` superuser is implemented on self-hosted deployments vs. managed cloud deployments. Elasticsearch has two distinct security realms: `file` and `native`. On a self-hosted deployment, the `elastic` superuser is represented as a document in the `.security` index, whereas in a cloud deployment `elastic` is defined in the `ES_PATH_CONF/users` and `ES_PATH_CONF/user_roles` files placed on each node in the cluster. The TransportChangePasswordAction impl is designed to update the password for users in the `native` realm specifically, and a failure on cloud to change the password for `elastic` using the Change Password API fails with the error that the user does not exist. The solution here leverages `fileUserPasswdStore.userExists` to do a low cost check on whether the request username belongs to the `file` realm and will exit early with an informative error message if that is the case.
ankit--sethi
added
>bug
:Security/Security
|
Hi @ankit--sethi, I've created a changelog YAML for you. |
|
Pinging @elastic/es-security (Team:Security) |
…uestions around CI/CD are resolved.
…' into feature/misleading-error-message
|
Hi @ankit--sethi, I've updated the changelog YAML for you. |
tvernum
reviewed
May 8, 2025
| Optional<Realm> realm = realms.stream().filter(t -> FileRealmSettings.TYPE.equalsIgnoreCase(t.type())).findAny(); | ||
| if (user == null && realm.isPresent()) { | ||
| // we should check if this request is mistakenly trying to reset a file realm user | ||
| FileRealm fileRealm = (FileRealm) realm.get(); |
There was a problem hiding this comment.
Why only file realms? Couldn't we just do this for all realms?
There was a problem hiding this comment.
fair point, maybe we can? I'm gonna take a closer look to see if there are any gotchas to doing that.
…' into feature/misleading-error-message
...rc/main/java/org/elasticsearch/xpack/security/action/user/TransportChangePasswordAction.java
Outdated
Show resolved
Hide resolved
...rc/main/java/org/elasticsearch/xpack/security/action/user/TransportChangePasswordAction.java
Outdated
Show resolved
Hide resolved
.../src/main/java/org/elasticsearch/xpack/core/security/authc/esnative/ClientReservedRealm.java
Outdated
Show resolved
Hide resolved
...st/java/org/elasticsearch/xpack/security/action/user/TransportChangePasswordActionTests.java
Show resolved
Hide resolved
...rc/main/java/org/elasticsearch/xpack/security/action/user/TransportChangePasswordAction.java
Show resolved
Hide resolved
…ecurity/action/user/TransportChangePasswordAction.java Co-authored-by: Slobodan Adamović <slobodanadamovic@users.noreply.github.com>
…security/authc/esnative/ClientReservedRealm.java Co-authored-by: Slobodan Adamović <slobodanadamovic@users.noreply.github.com>
…' into feature/misleading-error-message # Conflicts: # x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/authc/esnative/ClientReservedRealm.java
slobodanadamovic
approved these changes
Jun 13, 2025
ankit--sethi
added a commit
to ankit--sethi/elasticsearch
that referenced
this pull request
Jun 13, 2025
…ealm (elastic#127621) * This PR addresses elastic#113535 - a confusing error message when the user attempts to update the password for the `elastic` superuser in a cloud deployment. At the heart of the issue is the difference in how the `elastic` superuser is implemented on self-hosted deployments vs. managed cloud deployments. Elasticsearch has two distinct security realms: `file` and `native`. On a self-hosted deployment, the `elastic` superuser is represented as a document in the `.security` index, whereas in a cloud deployment `elastic` is defined in the `ES_PATH_CONF/users` and `ES_PATH_CONF/user_roles` files placed on each node in the cluster. The TransportChangePasswordAction impl is designed to update the password for users in the `native` realm specifically, and a failure on cloud to change the password for `elastic` using the Change Password API fails with the error that the user does not exist. The solution here leverages `fileUserPasswdStore.userExists` to do a low cost check on whether the request username belongs to the `file` realm and will exit early with an informative error message if that is the case. * Update docs/changelog/127621.yaml * re-do the ticket in Continuation-passing style. Previous unanswered questions around CI/CD are resolved. * link issue * accidental commit, reverting * Update docs/changelog/127621.yaml * try to check for membership in all non-native realms * [CI] Auto commit changes from spotless * improve checks to fix failing tests * improve * improve * improve logic with GroupedActionListener * return early * extra spaces * revert * Update x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/action/user/TransportChangePasswordAction.java Co-authored-by: Slobodan Adamović <slobodanadamovic@users.noreply.github.com> * Update x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/authc/esnative/ClientReservedRealm.java Co-authored-by: Slobodan Adamović <slobodanadamovic@users.noreply.github.com> * PR feedback * fix imports * fix test * add test --------- Co-authored-by: elasticsearchmachine <infra-root+elasticsearchmachine@elastic.co> Co-authored-by: Slobodan Adamović <slobodanadamovic@users.noreply.github.com>
ankit--sethi
added a commit
to ankit--sethi/elasticsearch
that referenced
this pull request
Jun 13, 2025
…ealm (elastic#127621) * This PR addresses elastic#113535 - a confusing error message when the user attempts to update the password for the `elastic` superuser in a cloud deployment. At the heart of the issue is the difference in how the `elastic` superuser is implemented on self-hosted deployments vs. managed cloud deployments. Elasticsearch has two distinct security realms: `file` and `native`. On a self-hosted deployment, the `elastic` superuser is represented as a document in the `.security` index, whereas in a cloud deployment `elastic` is defined in the `ES_PATH_CONF/users` and `ES_PATH_CONF/user_roles` files placed on each node in the cluster. The TransportChangePasswordAction impl is designed to update the password for users in the `native` realm specifically, and a failure on cloud to change the password for `elastic` using the Change Password API fails with the error that the user does not exist. The solution here leverages `fileUserPasswdStore.userExists` to do a low cost check on whether the request username belongs to the `file` realm and will exit early with an informative error message if that is the case. * Update docs/changelog/127621.yaml * re-do the ticket in Continuation-passing style. Previous unanswered questions around CI/CD are resolved. * link issue * accidental commit, reverting * Update docs/changelog/127621.yaml * try to check for membership in all non-native realms * [CI] Auto commit changes from spotless * improve checks to fix failing tests * improve * improve * improve logic with GroupedActionListener * return early * extra spaces * revert * Update x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/action/user/TransportChangePasswordAction.java Co-authored-by: Slobodan Adamović <slobodanadamovic@users.noreply.github.com> * Update x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/authc/esnative/ClientReservedRealm.java Co-authored-by: Slobodan Adamović <slobodanadamovic@users.noreply.github.com> * PR feedback * fix imports * fix test * add test --------- Co-authored-by: elasticsearchmachine <infra-root+elasticsearchmachine@elastic.co> Co-authored-by: Slobodan Adamović <slobodanadamovic@users.noreply.github.com>
ankit--sethi
added a commit
to ankit--sethi/elasticsearch
that referenced
this pull request
Jun 13, 2025
…ealm (elastic#127621) * This PR addresses elastic#113535 - a confusing error message when the user attempts to update the password for the `elastic` superuser in a cloud deployment. At the heart of the issue is the difference in how the `elastic` superuser is implemented on self-hosted deployments vs. managed cloud deployments. Elasticsearch has two distinct security realms: `file` and `native`. On a self-hosted deployment, the `elastic` superuser is represented as a document in the `.security` index, whereas in a cloud deployment `elastic` is defined in the `ES_PATH_CONF/users` and `ES_PATH_CONF/user_roles` files placed on each node in the cluster. The TransportChangePasswordAction impl is designed to update the password for users in the `native` realm specifically, and a failure on cloud to change the password for `elastic` using the Change Password API fails with the error that the user does not exist. The solution here leverages `fileUserPasswdStore.userExists` to do a low cost check on whether the request username belongs to the `file` realm and will exit early with an informative error message if that is the case. * Update docs/changelog/127621.yaml * re-do the ticket in Continuation-passing style. Previous unanswered questions around CI/CD are resolved. * link issue * accidental commit, reverting * Update docs/changelog/127621.yaml * try to check for membership in all non-native realms * [CI] Auto commit changes from spotless * improve checks to fix failing tests * improve * improve * improve logic with GroupedActionListener * return early * extra spaces * revert * Update x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/action/user/TransportChangePasswordAction.java Co-authored-by: Slobodan Adamović <slobodanadamovic@users.noreply.github.com> * Update x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/authc/esnative/ClientReservedRealm.java Co-authored-by: Slobodan Adamović <slobodanadamovic@users.noreply.github.com> * PR feedback * fix imports * fix test * add test --------- Co-authored-by: elasticsearchmachine <infra-root+elasticsearchmachine@elastic.co> Co-authored-by: Slobodan Adamović <slobodanadamovic@users.noreply.github.com>
ankit--sethi
added a commit
to ankit--sethi/elasticsearch
that referenced
this pull request
Jun 13, 2025
…ealm (elastic#127621) * This PR addresses elastic#113535 - a confusing error message when the user attempts to update the password for the `elastic` superuser in a cloud deployment. At the heart of the issue is the difference in how the `elastic` superuser is implemented on self-hosted deployments vs. managed cloud deployments. Elasticsearch has two distinct security realms: `file` and `native`. On a self-hosted deployment, the `elastic` superuser is represented as a document in the `.security` index, whereas in a cloud deployment `elastic` is defined in the `ES_PATH_CONF/users` and `ES_PATH_CONF/user_roles` files placed on each node in the cluster. The TransportChangePasswordAction impl is designed to update the password for users in the `native` realm specifically, and a failure on cloud to change the password for `elastic` using the Change Password API fails with the error that the user does not exist. The solution here leverages `fileUserPasswdStore.userExists` to do a low cost check on whether the request username belongs to the `file` realm and will exit early with an informative error message if that is the case. * Update docs/changelog/127621.yaml * re-do the ticket in Continuation-passing style. Previous unanswered questions around CI/CD are resolved. * link issue * accidental commit, reverting * Update docs/changelog/127621.yaml * try to check for membership in all non-native realms * [CI] Auto commit changes from spotless * improve checks to fix failing tests * improve * improve * improve logic with GroupedActionListener * return early * extra spaces * revert * Update x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/action/user/TransportChangePasswordAction.java Co-authored-by: Slobodan Adamović <slobodanadamovic@users.noreply.github.com> * Update x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/authc/esnative/ClientReservedRealm.java Co-authored-by: Slobodan Adamović <slobodanadamovic@users.noreply.github.com> * PR feedback * fix imports * fix test * add test --------- Co-authored-by: elasticsearchmachine <infra-root+elasticsearchmachine@elastic.co> Co-authored-by: Slobodan Adamović <slobodanadamovic@users.noreply.github.com>
elasticsearchmachine
pushed a commit
that referenced
this pull request
Jun 13, 2025
…ealm (#127621) (#129433) * This PR addresses #113535 - a confusing error message when the user attempts to update the password for the `elastic` superuser in a cloud deployment. At the heart of the issue is the difference in how the `elastic` superuser is implemented on self-hosted deployments vs. managed cloud deployments. Elasticsearch has two distinct security realms: `file` and `native`. On a self-hosted deployment, the `elastic` superuser is represented as a document in the `.security` index, whereas in a cloud deployment `elastic` is defined in the `ES_PATH_CONF/users` and `ES_PATH_CONF/user_roles` files placed on each node in the cluster. The TransportChangePasswordAction impl is designed to update the password for users in the `native` realm specifically, and a failure on cloud to change the password for `elastic` using the Change Password API fails with the error that the user does not exist. The solution here leverages `fileUserPasswdStore.userExists` to do a low cost check on whether the request username belongs to the `file` realm and will exit early with an informative error message if that is the case. * Update docs/changelog/127621.yaml * re-do the ticket in Continuation-passing style. Previous unanswered questions around CI/CD are resolved. * link issue * accidental commit, reverting * Update docs/changelog/127621.yaml * try to check for membership in all non-native realms * [CI] Auto commit changes from spotless * improve checks to fix failing tests * improve * improve * improve logic with GroupedActionListener * return early * extra spaces * revert * Update x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/action/user/TransportChangePasswordAction.java * Update x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/authc/esnative/ClientReservedRealm.java * PR feedback * fix imports * fix test * add test --------- Co-authored-by: elasticsearchmachine <infra-root+elasticsearchmachine@elastic.co> Co-authored-by: Slobodan Adamović <slobodanadamovic@users.noreply.github.com>
elasticsearchmachine
pushed a commit
that referenced
this pull request
Jun 13, 2025
…ealm (#127621) (#129435) * This PR addresses #113535 - a confusing error message when the user attempts to update the password for the `elastic` superuser in a cloud deployment. At the heart of the issue is the difference in how the `elastic` superuser is implemented on self-hosted deployments vs. managed cloud deployments. Elasticsearch has two distinct security realms: `file` and `native`. On a self-hosted deployment, the `elastic` superuser is represented as a document in the `.security` index, whereas in a cloud deployment `elastic` is defined in the `ES_PATH_CONF/users` and `ES_PATH_CONF/user_roles` files placed on each node in the cluster. The TransportChangePasswordAction impl is designed to update the password for users in the `native` realm specifically, and a failure on cloud to change the password for `elastic` using the Change Password API fails with the error that the user does not exist. The solution here leverages `fileUserPasswdStore.userExists` to do a low cost check on whether the request username belongs to the `file` realm and will exit early with an informative error message if that is the case. * Update docs/changelog/127621.yaml * re-do the ticket in Continuation-passing style. Previous unanswered questions around CI/CD are resolved. * link issue * accidental commit, reverting * Update docs/changelog/127621.yaml * try to check for membership in all non-native realms * [CI] Auto commit changes from spotless * improve checks to fix failing tests * improve * improve * improve logic with GroupedActionListener * return early * extra spaces * revert * Update x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/action/user/TransportChangePasswordAction.java * Update x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/authc/esnative/ClientReservedRealm.java * PR feedback * fix imports * fix test * add test --------- Co-authored-by: elasticsearchmachine <infra-root+elasticsearchmachine@elastic.co> Co-authored-by: Slobodan Adamović <slobodanadamovic@users.noreply.github.com>
elasticsearchmachine
pushed a commit
that referenced
this pull request
Jun 13, 2025
…ealm (#127621) (#129434) * This PR addresses #113535 - a confusing error message when the user attempts to update the password for the `elastic` superuser in a cloud deployment. At the heart of the issue is the difference in how the `elastic` superuser is implemented on self-hosted deployments vs. managed cloud deployments. Elasticsearch has two distinct security realms: `file` and `native`. On a self-hosted deployment, the `elastic` superuser is represented as a document in the `.security` index, whereas in a cloud deployment `elastic` is defined in the `ES_PATH_CONF/users` and `ES_PATH_CONF/user_roles` files placed on each node in the cluster. The TransportChangePasswordAction impl is designed to update the password for users in the `native` realm specifically, and a failure on cloud to change the password for `elastic` using the Change Password API fails with the error that the user does not exist. The solution here leverages `fileUserPasswdStore.userExists` to do a low cost check on whether the request username belongs to the `file` realm and will exit early with an informative error message if that is the case. * Update docs/changelog/127621.yaml * re-do the ticket in Continuation-passing style. Previous unanswered questions around CI/CD are resolved. * link issue * accidental commit, reverting * Update docs/changelog/127621.yaml * try to check for membership in all non-native realms * [CI] Auto commit changes from spotless * improve checks to fix failing tests * improve * improve * improve logic with GroupedActionListener * return early * extra spaces * revert * Update x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/action/user/TransportChangePasswordAction.java * Update x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/authc/esnative/ClientReservedRealm.java * PR feedback * fix imports * fix test * add test --------- Co-authored-by: elasticsearchmachine <infra-root+elasticsearchmachine@elastic.co> Co-authored-by: Slobodan Adamović <slobodanadamovic@users.noreply.github.com>
elasticsearchmachine
pushed a commit
that referenced
this pull request
Jun 13, 2025
…ealm (#127621) (#129432) * This PR addresses #113535 - a confusing error message when the user attempts to update the password for the `elastic` superuser in a cloud deployment. At the heart of the issue is the difference in how the `elastic` superuser is implemented on self-hosted deployments vs. managed cloud deployments. Elasticsearch has two distinct security realms: `file` and `native`. On a self-hosted deployment, the `elastic` superuser is represented as a document in the `.security` index, whereas in a cloud deployment `elastic` is defined in the `ES_PATH_CONF/users` and `ES_PATH_CONF/user_roles` files placed on each node in the cluster. The TransportChangePasswordAction impl is designed to update the password for users in the `native` realm specifically, and a failure on cloud to change the password for `elastic` using the Change Password API fails with the error that the user does not exist. The solution here leverages `fileUserPasswdStore.userExists` to do a low cost check on whether the request username belongs to the `file` realm and will exit early with an informative error message if that is the case. * Update docs/changelog/127621.yaml * re-do the ticket in Continuation-passing style. Previous unanswered questions around CI/CD are resolved. * link issue * accidental commit, reverting * Update docs/changelog/127621.yaml * try to check for membership in all non-native realms * [CI] Auto commit changes from spotless * improve checks to fix failing tests * improve * improve * improve logic with GroupedActionListener * return early * extra spaces * revert * Update x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/action/user/TransportChangePasswordAction.java * Update x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/authc/esnative/ClientReservedRealm.java * PR feedback * fix imports * fix test * add test --------- Co-authored-by: elasticsearchmachine <infra-root+elasticsearchmachine@elastic.co> Co-authored-by: Slobodan Adamović <slobodanadamovic@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR addresses #113535 - a confusing error message when the user attempts to update the password for the
elasticsuperuser in a cloud deployment.At the heart of the issue is the difference in how the
elasticsuperuser is implemented on self-hosted deployments vs. managed cloud deployments. Elasticsearch has two distinct security realms:fileandnative. On a self-hosted deployment, theelasticsuperuser is represented as a document in the.securityindex (placing it in thenativerealm), whereas in a cloud deploymentelasticis defined in theES_PATH_CONF/usersandES_PATH_CONF/user_rolesfiles installed on each node in the cluster (placing it in thefilerealm).The
TransportChangePasswordActionimpl is designed to update the password for users in thenativerealm specifically, and on cloud an attempt to change the password forelasticusing the Change Password API fails with the error that the user does not exist. This is misleading since the user exists but is simply coming from thefilerealm.The solution here first checks if any of the reserved realm users are being updated in a cluster where the reserved realm has been turned off. This reflects the typical cloud use case that causes #113535.
In addition, if the API detects that the user principal is not a native/reserved user, it attempts to search for the user in all other active realms. Performing this check helps give smarter feedback to the user, i.e., that the user is present in some other realm, instead of a generic "user not found" error that may be confusing to someone who knows the user exists but is not informed about the different realms.