definitions.json that holds a username and password for rabbit cannot be templated / used with a secret

[yitzhaktal]

Is your feature request related to a problem? Please describe.
When using the CRD for RabbitMQCluster Operator, I'd like to import definitions.json including vhost / and default user, but there is no option to template the username and password or exposing it via secret.

Describe the solution you'd like
Dedicated field for providing a secret with user name and password for rabbit.

Describe alternatives you've considered
Run a postStart commands to align the password aside the definitions.json:

                lifecycle:
                  postStart:
                    exec:
                      command:
                        - "/bin/sh"
                        - "-c"
                        - |
                          rabbitmqctl wait --pid 1 --timeout 60 && \
                          rabbitmqctl list_users | grep -q $RABBITMQ_DEFAULT_USER || \
                          (rabbitmqctl add_user $RABBITMQ_DEFAULT_USER $RABBITMQ_DEFAULT_PASS && \
                          rabbitmqctl set_user_tags $RABBITMQ_DEFAULT_USER administrator && \
                          rabbitmqctl set_permissions -p / $RABBITMQ_DEFAULT_USER ".*" ".*" ".*")

[lukebakken]

@Zerpet is much more familiar with this project than I am.

My guess is that this project assumes it's your responsibility to pre-generate definitions.json to be used with the operator via this mechanism: https://github.com/rabbitmq/cluster-operator/tree/main/docs/examples/import-definitions

[mkuratczyk]

Why is it important for the imported user to be the "default user"? If you import user(s) from the definitions file, they will work just fine. There's just one additional user, with a very hard to guess username and password, which gets created by the Operator. You can just not use this user and ignore its existence completely.

[yitzhaktal]

The issue is about the fact that it's not possible to declare a user in the definitions.json with a password that is templated or declared in a k8s secret.

[mkuratczyk]

If it was up to me, we would have one operator, not two. ;) But either way, having an additional operator doesn't sound that bad too me.

Looking at the bitnami's chart issue, I don't really see any solutions there - you just either put the definitions in a values file directly or in a secret. How does that help?

Here is another option that (mostly) works right now: define the FOO-default-user secret before deploying RabbitMQ with default_user.conf set to the value you want. For example:

1. Create a base64 value for the default user:

$ echo -e "default_user = foobar\ndefault_pass = foobar" | base64
ZGVmYXVsdF91c2VyID0gZm9vYmFyCmRlZmF1bHRfcGFzcyA9IGZvb2Jhcgo=

2. Create a secret with that value:

apiVersion: v1
kind: Secret
metadata:
  name: rmq-default-user
data:
  default_user.conf: ZGVmYXVsdF91c2VyID0gZm9vYmFyCmRlZmF1bHRfcGFzcyA9IGZvb2Jhcgo=

Now if you create a RabbitMQ instance called rmq, it will use this secret and your default user will be foobar/foobar. I believe this is basically what you want and there's no need to synchronize anything - the secret is picked up on the initial boot.
I said "mostly works", because this secret should contain additional fields but apparently they are not added if the secret exists (is not created by the Operator). Perhaps this is what we should fix - if the user is pre-defined in the default-user field of the secret, then all the missing fields should be added correctly. If you like this solution - a PR to make it fully work would be appreciated.

One last idea I have is to allow multiple definition files. This could happen on one of two levels:

1. On the Kubernetes level, we could allow specifying multiple ConfigMaps and Secrets and merge them so that RabbitMQ still just sees a single JSON value.
2. On the RabbitMQ level, we could allow specifying multiple definitions files to load. However, I'd rather avoid this, since the definition import is already pretty complex.

[Zerpet]

The issue is about the fact that it's not possible to declare a user in the definitions.json with a password that is templated or declared in a k8s secret.

Yes, indeed, it is not possible, and I don't see a compelling argument to be otherwise. You are essentially asking a Kubernetes Operator to become a JSON templating machine.

There are already libraries and tools out in the wild to do JSON templating, and they will do it a lot better than anything we write from scratch. You can write the templating logic yourself to manipulate a definitions file, and then either toss that into a configMap/secret, and follow the example to import definitions; or make that JSON available via HTTP and follow the example to import over HTTP.

[lukebakken]

On the RabbitMQ level, we could allow specifying multiple definitions files to load

This is already supported via definitions.local_path - https://www.rabbitmq.com/docs/definitions#import-on-boot

[mkuratczyk]

Thanks Luke, I didn't know it was already supported! I've put together an example which takes advantage of this feature to split the definitions into a Secret with user(s) definition(s) and a ConfigMap with everything else:
#1802

I hope this solves your problem @yitzhaktal

[yitzhaktal]

Yes, this is very nice! Thanks :)

[grubbymediator]

Is this the recommended way to automatically seed service accounts on prod environments?
To have a separate non-secret definitions file for topology, and another one with users and perms wholly planted from secrets by script?