Add support for parsing default user credentials from JSON

[itspngu]

Is your feature request related to a problem? Please describe.

The default user credential updater sidecar expects the file it reads username + password from (default /etc/rabbitmq/conf.d/11-default_user.conf, configurable via the default-user-file parameter) to be INI-formatted. Support for additional formats (though the only one with a valid use-case that I'm aware of would be JSON) would be desirable.

While the Vault Provider for the Secrets Store CSI driver is referenced in the RabbitMQ Cluster Operator's docs, it can't actually be used, because it lacks the means to run transformations/templating on the secrets it fetches from Vault. It can either render the entire secret into a file as-is, or render a specified sub-key of the secret into a file, that's it. What it can do is get the .Data.data sub-key of a KVv2 secret, which is JSON, and render that into a file (as JSON, without further processing).

Describe the solution you'd like

Have the default user credential updater sidecar dynamically react to different data formats and render the output file that RabbitMQ uses regardless of input format. This could be done by looking at the file extension, or, preferably, by parsing the file and then figuring out if the data therein is digestible (e.g. try to serialize from JSON, if that fails, try reading it as an INI, etc).

Describe alternatives you've considered

This limitation can be worked around by creating the Vault secret not as outlined in the the docs (as a JSON-encoded object with a username and password key), but instead as an INI-encoded representation thereof, but that feels... wrong. Furthermore, the way the RabbitMQ Cluster Operator leverages a Vault Agent sidecar to render these credentials into the cluster's pods would be incompatible with that approach (not that you'd use both at the same time anyway) because it (indirectly) renders a Vault Agent config expecting the secret to be formatted as JSON.

This could be workaround-workarounded by creating a secret containing a username key, a password key, and a default_user_creds_ini_in_base64_oh_no key. I hate myself for even coming up with that idea.

Additional context

As far as I can tell, the /etc/rabbitmq/conf.d/11-default_user.conf file is not used by anything other than the default-user-credential-updater sidecar. If that's correct, this would be the best place to implement the feature and also retain compatibility to the Vault Agent based approach of the Operator, or custom solutions users might have come up with.

Happy to put in a PR for this once given the go-ahead.

[MirahImage]

This sounds like a very useful enhancement. We're going to have a quick chat about it in the team to see if we have any detailed thoughts or suggestions.

[Zerpet]

I agree this will be useful to add to this sidecar program. I'll be happy to review a PR.