I don't know how this translates into rabbit ACLs, but you can see how the collective is mixed into the names:
https://github.com/puppetlabs/marionette-collective/blob/master/lib/mcollective/connector/rabbitmq.rb#L407-L427 Of course this is done not using AMQP but via the Stomp plugin for RabbitMQ so that'll be interesting to get going. Most recently I reckon the model I built here http://choria.io/docs/federation/ is a much easier to secure system. On Wed, May 3, 2017, at 13:31, Turbo Fredriksson wrote: > I currently have many collectives (so I can target specific services > easily), but only one > username/password for all of them. > > I'm planning on making sure that each environment/service have their own > username/password > for RabbitMQ, so that a hacked system don't compromise the whole. > > I've reread the > https://docs.puppet.com/mcollective/reference/plugins/connector_rabbitmq.html > documentation (which is what I'm running now). But it's not clear on how > to > limit this. > > It only say: > > rabbitmqadmin declare permission vhost=/mcollective user=mcollective > configure='.*' write='.*' read='.*' > > which, from how I'm reading it, gives the mcollective user full access to > the whole vhost! > > Obviously, that's not how I want it in production. So how can I say that > the user "xyz" should > only be able to write to the collective(s) it's in? > > Each host is part of many collectives, in a tree structure. It looks > something like this: > > core > environment > environment-location > environment-location-service > > Sometimes environment=location, in which case the '-location' part isn't > used. > That way I can target it/them individually (without know their individual > identity name) or with a "scatter gun" > (targeting ALL instances from the "core" collective). > > Actual config (for the Puppet master): > > collectives = core,core-management,core-management-puppet > main_collective = core-management-puppet > > and for one of the app servers: > > collectives = core,test,test-app > main_collective = test-app > > > Problem here is that they're ALL in the 'core' collective. That's only to > make sure that > it's accessible from the MCO client (which is main collective is 'core' - > othervise it > won't see all instances for some reason). > > -- > > --- > You received this message because you are subscribed to the Google Groups > "mcollective-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to mcollective-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- R.I.Pienaar / www.devco.net / @ripienaar -- --- You received this message because you are subscribed to the Google Groups "mcollective-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to mcollective-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
