CODEWITHSUNDEEP
authenticationrabbitmqrabbitmq-exchangerabbitmq-federation
Edd
Edd

Reputation: 8570

What are the minimal access rights for the upstream user when using RabbitMQ Exchange Federation

I want to ensure that all users on my RabbitMQ clusters only have the rights they need for their intended purpose.

I'm using Exchange Federation between 2 RabbitMQ clusters and I want to restrict the rights of the user on the upstream cluster so that it can only federate messages from one Exchange. This is to ensure that the user used by the downstream cluster is not able to publish/subscribe/configure anything beyond it's intended purpose (or at least as much as is possible).

I understand that the permissions may be complex, as a worker queue and bindings must be dynamically created on the upstream cluster so this may not be straightforward.

All examples I've found specify to set the user's permissions as:

Configure regexp Write regexp Read regexp
.* .* .*

The federation works fine when the user has these settings but this is an all powerful user and I'm not comfortable with this. If I try to reconfigure it to anything more specific then I end up an error like the below:

{server_initiated_close,403,
<<"ACCESS_REFUSED - access to exchange 'exchange-a' in vhost 'vhost-a' refused for user 'user-a'">>}

How can I restrict these permissions to prevent the federation user having more access than it needs?

Upvotes: 0

Views: 427

Answers (1)

Edd
Edd

Reputation: 8570

I've not found an answer to this question in any of my books or online resources so this answer is based on observation and trial and error....

Solution

Exchange federation seems to require an upstream user which has permissions to read from the target upstream exchange and also to configure, read and write to an upstream federation exchange and queue which are dynamically created.

The names of the dynamically created exchange and queue use the original exchange name and are both prefixed with federation: and suffixed with -> and the downstream cluster name. The dynamically created exchange is also suffixed by an additional letter of the alphabet.

Based on this I have found that these minimal access rights work very nicely (with the exchange and downstream cluster names corrected):

Configure regexp Write regexp Read regexp
^federation: exc\.name -> dwn_cluster_name ^federation: exc\.name -> dwn_cluster_name ^exc\.name$|^federation: exc\.name -> dwn_cluster_name

Example

Let's say I have an exchange called my.exchange. The minimal access rights to read from this exchange alone would be ^my\.exchange$.

When a federation policy is setup on the downstream a new exchange and queue are created on the upstream cluster. These have names as shown below:

  • Exchange name: federation: my.exchange -> MY_DOWNSTREAM_CLUSTER A (final character can vary)
  • Queue name: federation: my.exchange -> MY_DOWNSTREAM_CLUSTER

Permissions can therefore be setup as:

Configure regexp Write regexp Read regexp
^federation: my\.exchange -> MY_DOWNSTREAM_CLUSTER ^federation: my\.exchange -> MY_DOWNSTREAM_CLUSTER ^my\.exchange$|^federation: my\.exchange -> MY_DOWNSTREAM_CLUSTER

What about federated queues?

Obviously off topic but worth answering here anyway as relatively simple by comparison.

This is simply a case of needing both configure and read permissions for the queue itself. Therefore a very explicit pattern for a full line match can be used for these e.g. ^my\.queue$.

Configure regexp Write regexp Read regexp
^my\.queue$ ^$ ^my\.queue$

Upvotes: 0

Related Questions