Closed netic-rkm closed 2 months ago
It's not clear to me what you mean. Please provide an executable test case (kubectl/rabbitmqctl commands we can use to see the problem).
Here is a manifest, hope that makes it more clear
---
#
# Vhost created in namespace for the application foo
#
apiVersion: rabbitmq.com/v1beta1
kind: Vhost
metadata:
name: private-vhost
namespace: foo
spec:
name: private-vhost
rabbitmqClusterReference:
name: rabbitmq-delayed-messaging
namespace: rabbitmq-system
---
#
# User created in an other namespace
#
apiVersion: rabbitmq.com/v1beta1
kind: User
metadata:
name: other-user
namespace: bar
spec:
rabbitmqClusterReference:
name: rabbitmq
namespace: rabbitmq-system
tags:
- administrator
---
#
# I am able to give permissions to a vhost that is in an other namespace
#
apiVersion: rabbitmq.com/v1beta1
kind: Permission
metadata:
name: other-user-permission
namespace: bar
spec:
permissions:
configure: .*
read: .*
write: .*
rabbitmqClusterReference:
name: rabbitmq-delayed-messaging
namespace: rabbitmq-system
userReference:
name: other-user
vhost: private-vhost
Isn't that the behaviour we document at the very top of the docs? https://www.rabbitmq.com/kubernetes/operator/using-topology-operator#namespace-scope
You already created a vhost in a different namespace than the cluster. You also created the user in a different namespace than the cluster. Permissions are not treated differentely.
In the future, please provide a fully executable example, so that maintainers can simply kubectl apply
what you shared and see that working (so that'd include the namespaces required, clusters referenced and whatever else).
@mkuratczyk I will remember to have a full executable next time.
the problem with the current implementation is that the annotation "rabbitmq.com/topology-allowed-namespaces" is only on the cluster, so if i want to make sure one development team can't create users that have permissions to queues or vhosts that they did not create I would have to run multiple clusters.
Adding support for vhost level annotation to allow specific namespaces only with perhaps a special value meaning "same namespace only" (meaning, objects in this vhost can only come from the same namespace as the vhost itself) sounds reasonable to me.
If you are interested in such a feature, contributing it would be your best option.
This issue has been marked as stale due to 60 days of inactivity. Stale issues will be closed after a further 30 days of inactivity; please remove the stale label in order to prevent this occurring.
Closing stale issue due to further inactivity.
Is your feature request related to a problem? Please describe. If I create a vhost in the namespace foo, I am able to add a user and permissions to that vhost in the namespace bar.
Describe the solution you'd like I would like to be able to set a list of allowed namespaces on the vhost to limit the namespaces that can create permissions to it.
Describe alternatives you've considered I was considering a cluster per namespace, but it really feels like an anti pattern, and a waste of resources.
Additional context Non