Connection Secret: Use from other namespaces
thriqon opened this issue · 4 comments
Is your feature request related to a problem? Please describe.
Managing an external, but centrally managed RabbitMQ cluster with applications in different namespaces (which should not be exposed to the admin credentials) is currently impossible.
Describe the solution you'd like
The connectionSecret reference should allow setting the namespace of the connection secret. Additionally, restrictions on the namespaces allowed to do so should be possible (with the same annotation as the cluster object?).
Describe alternatives you've considered
Copying the connection secret to all application namespaces is possible, but highly undesirable (due to management issues and admin password exposure).
Additional context
#294 introduced the connection secret from #135.
Can you help us to better understand the problem you're trying to solve? Where is the RabbitMQ cluster located (in Kubernetes, elsewhere)? Are you trying to create users for a single RabbitMQ across multiple namespaces?
The cluster is external to Kubernetes. And yes, we are trying to use one cluster across multiple namespaces.
Crucially, the cluster is not managed by the Cluster Operator, which does have the option to use clusters cross-namespace.
We would rather not allow cross-namespace ability, as it breaks the namespace isolation that many of our users rely upon.
If you are concerned about replicating secrets across namespaces, secretgen controller can help with that.
If you are concerned about security, without additional controls such as admission webhooks (e.g. OPA validation), having the ability to create topology-operator users is equivalent to having admin user permissions on RabbitMQ, as it is possible to create a user with admin permissions via the topology operator.
I won't argue with you, as it is your project, but I am surprised about the isolation guarantees. The default way using the in-cluster StatefulSet does allow cross-namespace sharing, with support to specify and limit acceptable consumers.
Thanks anyway for your answer and an awesome project!