Change password of User

[ktzsolt]

Is your feature request related to a problem? Please describe.
Can not change password of Kind: User . Changing password values in importCredentialsSecret makes no effect as the docs state here:

messaging-topology-operator/docs/examples/users/README.md

Line 16 in 0c910d9

Note that Messaging Topology Operator does not watch the provided secret and updating the secret object won't update actual user credentials.

If you wish to update User credentials, you can update the secret generated by the controller and then add a label or annotation to the User object to trigger a reconcile loop.

Describe the solution you'd like
The importCredentialsSecret secret and the generated secret has the same data so it does not make sense to generate a different secret by the messaging-topology-operator with the same structure and same data that our importCredentialsSecret secret already has.

data:
  username:
  password:

The user credentials should come directly from the importCredentialsSecret and not the generated secret so when using helm to deploy we could use the checksum annotation trick (https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments) to change user password in our secret and trigger a reconcile for the User resource. Currently it is not possible to change the data in the generated secret with helm tooling (or I don't know how to do it)

Changing the user name of the Kind: User resource is not scope for this feature but easy password rotation with helm is.

Workarounds with helm tricks would be also welcome if somebody knows any!

related:
#924
#896
#242

[Zerpet]

I agree that duplicating the secret when there is an import-secret is not necessary. I'm all for supporting password rotation using this Helm trick. However, we cannot just blindly take any information from the provided Secret. I described my concern with how to handle the update when the username changes: #924 (comment)

This change would require to store state about the username (initial username created), and reject any changes that update the username. I don't think we can safely handle username updates, so the best path forward would be to outright reject such update.

[ktzsolt]

But one of the key point is to not support username change but to support password change and password change only and reject username change with the admission webhook.

Right now it is not really possible to change the password with helm upgrade because a manual steps needs to be done before issuing helm upgrade by the k8s admin, that is deleting the generated secret (and also use the helm checksum trick to trigger the rabbitmq user resource to reconcile on helm upgrade)

[Zerpet]

But one of the key point is to not support username change but to support password change and password change only and reject username change with the admission webhook.

Forgive me for missing a key point that was not mentioned in the OP 🙁

Again, I'm not against this change; quite the opposite, I like this proposal with limited scope to passwords. That being said, I don't have much bandwidth to work on this issue at the moment. A PR contribution would be most welcome.