It is not really natural to populate the authentications file, used to connect to the amqp broker, with data from a k8s secret (unless that secret is exactly a valid auth file). A more maintainable design, from a deployment perspective, is to create a secret with the RabbitMQ release and then use that secret in dripline releases. There are a few paths that could be considered:
A defined set of environment variables that are added to the parsing sequence along with CLI flags, passed in files, and defaults (eg RABBITMQ_USER etc.)
Using environment variables from a secret as arguments to CLI flags (maybe this is already supported but i'd need to remind myself of the syntax and consider if it would put those variables into history in an undesired way.
Add support to the parsing sequence for parsing the secrets as produced by standard or official rabbitmq releases, in particular, we're thinking of: https://hub.helm.sh/charts/stable/rabbitmq-ha
It is not really natural to populate the authentications file, used to connect to the amqp broker, with data from a k8s secret (unless that secret is exactly a valid auth file). A more maintainable design, from a deployment perspective, is to create a secret with the RabbitMQ release and then use that secret in dripline releases. There are a few paths that could be considered:
RABBITMQ_USERetc.)