Allow providing cleartext passwords for creating Elasticsearch users #5613
Conversation
This file contains 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
thbkrkr
reviewed
Apr 29, 2022
docs/orchestrating-elastic-stack-applications/security/users-and-roles.asciidoc
Outdated
Show resolved
Hide resolved
docs/orchestrating-elastic-stack-applications/security/users-and-roles.asciidoc
Outdated
Show resolved
Hide resolved
docs/orchestrating-elastic-stack-applications/security/users-and-roles.asciidoc
Outdated
Show resolved
Hide resolved
Co-authored-by: Thibault Richard <[email protected]>
thbkrkr
reviewed
Apr 29, 2022
docs/orchestrating-elastic-stack-applications/security/users-and-roles.asciidoc
Outdated
Show resolved
Hide resolved
thbkrkr
reviewed
Apr 29, 2022
docs/orchestrating-elastic-stack-applications/security/users-and-roles.asciidoc
Show resolved
Hide resolved
thbkrkr
reviewed
Apr 29, 2022
…nd-roles.asciidoc Co-authored-by: Thibault Richard <[email protected]>
barkbay
reviewed
May 3, 2022
docs/orchestrating-elastic-stack-applications/security/users-and-roles.asciidoc
Outdated
Show resolved
Hide resolved
Co-authored-by: Michael Morello <[email protected]>
barkbay
reviewed
May 10, 2022
Co-authored-by: Michael Morello <[email protected]>
|
run/e2e-tests tags=es |
barkbay
added
>feature
barkbay
changed the title
fantapsody
pushed a commit
to fantapsody/cloud-on-k8s
that referenced
this pull request
Feb 7, 2023
Add support for an additional form of secret following the https://kubernetes.io/docs/concepts/configuration/secret/#basic-authentication-secret format. It will allow users to specify username and a cleartext password. I also added support for a custom roles file in that secret. The idea being that a user that wants to create a user and assign a role to it does not need to create two separate secrets for that (one for the user and one for the users_role file). Instead they can list the roles to be assigned to the new user in the same secret as a comma separated list. We always supported setting a custom password for the elastic user through the file realm (because user defined ES users always take precedence) This change also removes the default elastic user secret if the elastic user is set up through the file realm. The rationale for this decision was to avoid having to sync the contents of both secrets (the user provided one and the operator created one) or have the contents diverge which might lead to confusion. Also we should not not create resources in the API server that are not needed Co-authored-by: Thibault Richard <[email protected]> Co-authored-by: Michael Morello <[email protected]>
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.
Fixes #3056
This PR adds support for an additional form of secret following the https://kubernetes.io/docs/concepts/configuration/secret/#basic-authentication-secret format. It will allow users to specify username and a cleartext password.
I also added support for the
users_rolesfile in that secret. The idea being that a user that wants to create a user and assign a role to it does not need to create two separate secrets for that (one for the user and one for theusers_rolefile). The counterargument is of course that we are now mixing Elasticsearch file realm content with the basic authentication secret which might be confusing in a different way.We always supported setting a custom password for the
elasticuser through the file realm (because user defined ES users always take precedence) This PR also removes the defaultelasticuser secret if theelasticuser is set up through the file realm. The rationale for this decision was to avoid having to sync the contents of both secrets (the user provided one and the operator created one) or have the contents diverge which might lead to confusion. Also we should not not create resources in the API server that are not needed.