Possibility to specify external secret for erlang cookie

[mattsve]

We are migrating from a k8s cluster based on a platform that is nearing end of life (we are using to a new open shift based platform.
In the old k8s cluster we are using the bitnami helm chart for installing rabbitmq and the plan is to use the rabbitmq operator for the new k8s cluster.
To ease migration we would like to add the rabbitmq nodes in the new k8s cluster to the old rabbitmq cluster while we wind down the old k8s cluster. Both the old and new k8s clusters are in the same datacenter so there should not be any problem with network latency.

To do this we need to be able to specify the erlang cookie when using rabbitmq operator.

[Zerpet]

Allowing the Erlang cookie from external secrets comes with certain risks that we are not comfortable with. For example, changes to the Erlang cookie for existing clusters. Once a cluster has been created, one could be tempted to rotate the Erlang cookie, because some security checklist says you must rotate all your secrets regularly; that's a terrible idea in Kubernetes, because the STS would try to restart the nodes 1 by 1, and this operation will never succeed there will be an Erlang cookie mismatch (rotated node vs "old" nodes).

Our team has experience with a product (Tanzu RabbitMQ for CF) that allows to set the Erlang cookie, and the amount of pain and issues that came as a result were simply too much. In the cluster-operator, we decided to remove erlang cookie customisation.

Specific to your issue, the best I can recommend is that you perform a blue-green migration. I recently wrote a blog post about it: https://www.rabbitmq.com/blog/2025/07/29/latest-benefits-of-rmq-and-migrating-to-qq-along-the-way

The blog post is applicable, even if you are not migrating CMQs to QQs.