Consider a "set user permission for all vhosts" CLI command

[michaelklishin]

Originally filed as rabbitmq/rabbitmq-management#293.

One thing that's immediately not obvious to me is what should happen when new vhosts are added, since this is an ongoing maintenance problem.

Also, as of 3.7.0 this can become a CLI plugin (once the new CLI is open sourced and integrated) instead of a built-in feature but some internal API hooks would help either way.

[coderanger]

Something like a special vhost name for permissions (*?) where those permissions apply to all vhosts would also fit the bill and would simplify management accounts a lot.

[25schmekles]

Bump.
I am often applying permission for multiple users to dozens of vhosts at a time. A bulk permissions application tool would speed that process up significantly.

[sbert]

It will be very useful

For ex to use with datadog

[cdobbyn]

Very useful indeed. This is management overhead that's unnecessary.

newrelic monitoring.

[h0jeZvgoxFepBQ2C]

Yeah this would be great!

[michaelklishin]

I am leaning towards a new command and not a special virtual host name. It's a pretty dangerous thing to do and someone might confuse which one of the four asterisks grants the permissions to all virtual hosts in the cluster.

[coderanger]

@michaelklishin I might be misunderstanding the code, that command looks like it only applies to vhosts that exist at that moment? If so, that doesn't really answer the issue. Imagine something like a monitoring user which needs read access to every vhost, even future ones.

[lukebakken]

that command looks like it only applies to vhosts that exist at that moment

Yes.

If so, that doesn't really answer the issue. Imagine something like a monitoring user which needs read access to every vhost, even future ones

Yes, this feature addresses a major part of the issue. @michaelklishin already made a comment with regard to future vhosts:

One thing that's immediately not obvious to me is what should happen when new vhosts are added, since this is an ongoing maintenance problem

[coderanger]

I would still vote to leave this issue open until the true "all vhosts" solution is worked out :) Or make a new one, either way.

[michaelklishin]

@coderanger yes, it only applies to virtual hosts that already exist. This is how most users interpreted this feature.

We do have a couple of features that "pre-configure" virtual hosts that will be created in the future but this is something very new: ##6172. Something similar for permissions makes sense but it'd need to be designed.

@illotum have you ever had a need for something like @coderanger is describing?

[illotum]

I have not heard of our customers requesting this.

And we don't provision users for operators at all. A little tangential: from the cloud platform perspective vhosts in general feel redundant.

[coderanger]

My specific use case here is KEDA autoscaling, creating a single platform-level "keda" user in Rabbit rather than having to coordinate with every team using it.

[michaelklishin]

@coderanger I have an outline of the same idea as in #6172 but for permissions in #7208.