Support PasswordHash in User type #886
Conversation
|
@NikSays, we have received your signed contributor license agreement. The review is usually completed within a week, but may take longer under certain circumstances. Another comment will be added to the pull request to notify you when the merge can proceed. |
|
Thank you for contributing this feature. I like the high level logic proposed.
I'm not sure we need to, can you elaborate on this? |
If `passwordHash` field is set, then `password` field is ignored and the resulting credential secret will contain only the hash. A passwordless user is created if the hash is an empty string.
1. Create a User with a hash and verify that the user exists, and can be authenticated. 2. Create a User with an empty hash and verify that the password was ignored, the user exists, and cannot be authenticated.
Unset username was handled correctly, but empty username resulted in an unclear error: "Error 405 (Error 405 from RabbitMQ: EOF):".
Rename user_settings.go to user.go to reflect its extended scope
userWithPasswordHash.yaml - Creating a User with SHA-512 hash. passwordlessUser.yaml - Creating a User with empty hash. Password field is ignored, paswordless user is created.
Describe the new structure of the `importCredentialsSecret` field
NikSays
force-pushed
the
password-hash
branch
from
232599e
to
138c602
Compare
I've realized that forcing SHA-512 is viable. It won't work only if someone needs to create the User with a SHA-256 hash without access to the original password, or if someone wants to use a custom hashing function provided by a plugin. Both scenarios seem unlikely. |
|
I've added unit and system tests, updated the documentation, regenerated the asciidoc and the CRD. Also the branch was rebased on top of main, to simplify the commit history. |
NikSays
changed the title
|
The latest changes look good to me. I'll merge after CI passes 🚀 |
|
Hi, @Zerpet, sorry to bother you. Could you please restart the CI workflow, there was a timeout starting the cluster operator, seems like a one-off issue. |
|
Thank you! |
Another feature that was implemented and released, but never documented. Related to rabbitmq/messaging-topology-operator/pull/886
|
@NikSays, VMware has approved your signed contributor license agreement. |
This closes #865, #866
Note to reviewers: remember to look at the commits in this PR and consider if they can be squashed
Note to contributors: remember to re-generate client set if there are any API changes
Summary Of Changes
The Secret specified in User's ImportCredentialsSecret may contain the
passwordHashfield.If the field is absent, the behavior is unchanged: the plain-text password is generated if necessary and stored in the credentials Secret.
If the
passwordHashfield is present, thenpasswordfield is ignored and the resulting credentials Secret will contain only the hash. This is done to prevent ambiguous situations where the hash doesn't correspond to the password. It also prevents the plain-text password being accidentally used over the hash.If the hash is an empty string, a passwordless user is created.
Additional Context
Currently the hash must be generated with the SHA512 algorithm. A way to specify another hashing algorithm needs to be added. I will add it as another field in the secret, but I'm concerned the documentation for importCredentialsSecret will become too complicated.
Todo
Specify hashing algorithm