[rabbitmq-discuss] RabbitMQ ACL suggestions?

[Gavin M. Roy]

I wanted to see what the current thinking about the state of ACL's in RabbitMQ are. I've been trying to lock down my clusters and have run into some quirks:

We've looked at doing passive queue declares to get queue depths for alerting, reporting and auto-scaling of our consumers. Unfortunately passive queue declares appear to require configure access. I can see why queue.declare requires this but passive commands perhaps should have a different bit setting?

Another one that seems a bit strange is in order to acknowledge message receipt (i.e. Basic.Ack) it appears that one has to have the write permission set for the given user+queue. I wanted to lock consumers to read and publishers to write but at least in the case of consuming without using autoAck, this is not possible.

In addition, we are currently doing all of our monitoring via the Management Plugin's API. Unfortunately to get any data, the user calling the API to list information requires administration access. I'd love to be able to let Nagios/Your_Monitoring_Solution_Here poll the Rabbit node and get data without giving it access to change all of the configuration state and remove users.

Are there any changes related to these areas planned for future releases?

Regards,

Gavin

[Jason J. W. Williams]

We've looked at doing passive queue declares to get queue depths for alerting, reporting and auto-scaling of our consumers. Unfortunately passive queue declares appear to require configure access. I can see why queue.declare requires this but passive commands perhaps should have a different bit setting?

We've moved to monitoring this with custom checks to the web API.

 

In addition, we are currently doing all of our monitoring via the Management Plugin's API. Unfortunately to get any data, the user calling the API to list information requires administration access. I'd love to be able to let Nagios/Your_Monitoring_Solution_Here poll the Rabbit node and get data without giving it access to change all of the configuration state and remove users.

That's actually something I've been wanting to bring up on the list. Currently, we give Nagios it's own user with admin access so it can use the REST API. We also have a provisioning user that is used to create (via the REST API) the various users our apps need in the individual Chef recipes (we wrote a Chef "library" to abstract out the API). It would be nice to have a "read only" admin type that doesn't allow that type of admin to create/change permissions, because it looks like outside of being able to change permissions that standard RMQ permissions apply to the API.

-J

[Gavin M. Roy]

On Wed, Jun 29, 2011 at 6:25 PM, Jason J. W. Williams <jasonjw...@gmail.com> wrote:

We've looked at doing passive queue declares to get queue depths for alerting, reporting and auto-scaling of our consumers. Unfortunately passive queue declares appear to require configure access. I can see why queue.declare requires this but passive commands perhaps should have a different bit setting?

We've moved to monitoring this with custom checks to the web API.

Same here, our main use case is auto-scaling with our consumer code, i.e. app looks to see how many messages are pending and if thresholds are met, will kick off new threads if allowed.

That's actually something I've been wanting to bring up on the list. Currently, we give Nagios it's own user with admin access so it can use the REST API. We also have a provisioning user that is used to create (via the REST API) the various users our apps need in the individual Chef recipes (we wrote a Chef "library" to abstract out the API). It would be nice to have a "read only" admin type that doesn't allow that type of admin to create/change permissions, because it looks like outside of being able to change permissions that standard RMQ permissions apply to the API.

Read-only admin or more granular ACL controls with R/W bits for each setting… either would satisfy my needs.

Gavin

[Matthias Radestock]

Gavin,

On 29/06/11 23:17, Gavin M. Roy wrote:
> We've looked at doing passive queue declares to get queue depths for
> alerting, reporting and auto-scaling of our consumers. Unfortunately
> passive queue declares appear to require configure access. I can see why
> queue.declare requires this but passive commands perhaps should have a
> different bit setting?

That will change in the next release - passive declare won't require any
permissions. The code change for that is already on 'default'.

> Another one that seems a bit strange is in order to acknowledge message
> receipt (i.e. Basic.Ack) it appears that one has to have the write
> permission set for the given user+queue.

That can't be right. basic.ack requires no permissions whatsoever.

> In addition, we are currently doing all of our monitoring via the
> Management Plugin's API. Unfortunately to get any data, the user calling
> the API to list information requires administration access. I'd love to
> be able to let Nagios/Your_Monitoring_Solution_Here poll the Rabbit node
> and get data without giving it access to change all of the configuration
> state and remove users.

Again, that should change in the next release. The code for it is going
through qa atm.

Regards,

Matthias.
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq...@lists.rabbitmq.com
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Gavin M. Roy]

On Wed, Jun 29, 2011 at 6:29 PM, Matthias Radestock <matt...@rabbitmq.com> wrote:

On 29/06/11 23:17, Gavin M. Roy wrote:

We've looked at doing passive queue declares to get queue depths for
alerting, reporting and auto-scaling of our consumers. Unfortunately
passive queue declares appear to require configure access. I can see why
queue.declare requires this but passive commands perhaps should have a
different bit setting?

That will change in the next release - passive declare won't require any permissions. The code change for that is already on 'default'.

Great :)

 

Another one that seems a bit strange is in order to acknowledge message
receipt (i.e. Basic.Ack) it appears that one has to have the write
permission set for the given user+queue.

That can't be right. basic.ack requires no permissions whatsoever.

Hmm ok, will take a look then, I could be thinking of something else then, it's been fuzzy sitting in the back of my head on my "to send an email about" list when I came across the passive declare bit today when locking that down.

 

In addition, we are currently doing all of our monitoring via the
Management Plugin's API. Unfortunately to get any data, the user calling
the API to list information requires administration access. I'd love to
be able to let Nagios/Your_Monitoring_Solution_Here poll the Rabbit node
and get data without giving it access to change all of the configuration
state and remove users.

Again, that should change in the next release. The code for it is going through qa atm.

 

Awesome, thanks! 

[Jason J. W. Williams]

Hi Matthias,

 

In addition, we are currently doing all of our monitoring via the
Management Plugin's API. Unfortunately to get any data, the user calling
the API to list information requires administration access. I'd love to
be able to let Nagios/Your_Monitoring_Solution_Here poll the Rabbit node
and get data without giving it access to change all of the configuration
state and remove users.

Again, that should change in the next release. The code for it is going through qa atm.

  

What form will this take? Is it going to be a new flag, or will API access no longer required the "admin" flag? Also, any idea on the rev #?

-J

[Simon MacMullen]

On 06/07/11 01:28, Jason J. W. Williams wrote:
> What form will this take? Is it going to be a new flag, or will API
> access no longer required the "admin" flag?

API access never required the admin flag in =< 2.5.1, just that
non-admins can only see their own stuff, and can't see broker-wide info
at all.

The admin flag has been replaced by a "tags" field for users. Users can
be given arbitrary tags within rabbitmq-server. rabbitmq-management then
checks for the following tags:

"administrator" (do everything, same as admin before)
"monitoring" (look at everything, but only touch your own stuff)
"management" (limited access to mgmt, same as non-admin before)

Note also that by giving a user no tags you can lock them out of mgmt
completely. This would be useful if (for example) you use secret queue
names as capabilities.

> Also, any idea on the rev #?

Well, it's landed on default now, but you'll need default of everything.
Not sure what all the revision numbers are.

Cheers, Simon
--
Simon MacMullen
RabbitMQ, VMware

[Jason J. W. Williams]

On Wed, Jul 6, 2011 at 3:51 AM, Simon MacMullen <si...@rabbitmq.com> wrote:

On 06/07/11 01:28, Jason J. W. Williams wrote:

What form will this take? Is it going to be a new flag, or will API
access no longer required the "admin" flag?

API access never required the admin flag in =< 2.5.1, just that non-admins can only see their own stuff, and can't see broker-wide info at all.

Ah OK. Thanks for the clarification.

 

The admin flag has been replaced by a "tags" field for users. Users can be given arbitrary tags within rabbitmq-server. rabbitmq-management then checks for the following tags:

"administrator" (do everything, same as admin before)
"monitoring" (look at everything, but only touch your own stuff)
"management" (limited access to mgmt, same as non-admin before)

Note also that by giving a user no tags you can lock them out of mgmt completely. This would be useful if (for example) you use secret queue names as capabilities.

This is very cool. 

 

Also, any idea on the rev #?

OK, I'll keep an eye out for it in the next release. Updating the book's chapter about the API. Thank you very much for your help.

-J