-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Limit the permission ressource to the namespace vhosts are created in. #832
Comments
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? 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 |
@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. |
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
The text was updated successfully, but these errors were encountered: