Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Creating a passwordless user #865

Open
NikSays opened this issue Aug 5, 2024 · 3 comments · May be fixed by #886
Open

Creating a passwordless user #865

NikSays opened this issue Aug 5, 2024 · 3 comments · May be fixed by #886

Comments

@NikSays
Copy link

NikSays commented Aug 5, 2024

Is your feature request related to a problem? Please describe.
RabbitMQ allows creating passwordless users. However when an User resource is added via this operator, the password is required. If the password is not provided, it is automatically generated.

Describe the solution you'd like
I see two possible solutions:

  1. If the secret has no password key, generate the password; but if the secret has password: "", disable password auth. (Not backwards compatible)
  2. Add a new noPassword: bool flag to UserSpec.

Describe alternatives you've considered
With the right configuration, password auth via AMQP can be disabled for all users, but not individually.

Additional context
Management API endpoint /api/users/*name* creates a paswordless user if password_hash: "".

I can implement the noPassword: bool solution and open a PR, just want to be sure that this isn't already possible, and that the maintainers are okay with this solution.
@MirahImage MirahImage mentioned this issue Aug 6, 2024
Open
@Zerpet
Copy link
Contributor

Zerpet commented Aug 29, 2024

This idea sounds good to me. The best solution would be to support password hash in the User spec (see #866), or in the ImportCredentialsSecret secret, from a field inside the Secret. The password hash could have more priority over the "plain" password, because it's a more secure alternative.
It's important to note that we must have the ability to distinguish between "empty string" and "not set". This essentially means that, if we go down the new spec field solution, that field will have to be a pointer.

@NikSays
Copy link
Author

NikSays commented Aug 31, 2024

The hashing_algorithm field in the UserSettings struct is currently hard-coded to rabbit_password_hashing_sha512. This is fine when the hash is generated by the controller, but the hash provided in the Secret might be either SHA512, SHA256, or MD5. The solutions I see are:

  1. The Secret has a new hashingAlgorithm field;
  2. The controller tries to detect the function used from the length of the hash;
  3. Only one algorithm is supported in the spec.

@NikSays NikSays linked a pull request Sep 14, 2024 that will close this issue
Draft
3 tasks
@bou3108
Copy link

bou3108 commented Sep 18, 2024

Hi,

It would be a high-value improvement for us. We use EXTERNAL authentication mechanism to authenticate external clients with mTLS only. They're supposed to be passwordless but they're currently created with a generated password.

We obviously don't share the generated passwords, but still, we're not happy with it.

Thanks @NikSays for the issue and the PR, we hope it could be merged soon !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Draft: Support PasswordHash in User type NikSays/messaging-topology-operator
3 participants
@Zerpet @NikSays @bou3108