On 6/14/19 8:38 AM, Jeremy Cline wrote: > Hi folks, > > Over the last couple days I've been sorta-kinda helping Adam move OpenQA > to AMQP and he has, through no fault of his own, had a rough time of it. > > The problems boil down to permissions issues and a lack of visibility > into the broker. I'd like to propose two changes so that folks can help > themselves rather than blindly guessing and hoping I am around (there is > a bus around every corner and lottery tickets in every shop). > > Firstly, I propose we allow authenticated users to create objects in the > /pubsub (private) vhost using the AMQP client. These users already can > create objects, but they have to do it through Ansible roles rather than > through the AMQP object. Since the AMQP client configuration is checked > into Ansible, though, it's rather redundant to make them declare the > queue separately. When they don't declare it properly, they can't tell > and so it's actually quite a pain point. This is an easy change, we just > change all the accounts to have configure permissions My fear here is that someone will manually create something and we have to redeploy for some reason. They will be broken untll they manually remember to do what they did again. :( Or does the ansible module override whats already there? > > Secondly, I propose we offer a read-only monitoring account to the web > interface RabbitMQ provides. One great thing about switching from ZeroMQ > to AMQP is that the broker gives us tons of tools to make monitoring and > debugging easier. Allowing users to easily see the objects in the broker > (queues, bindings, exchanges, connections) means they can solve their > own deployment problems rather than pinging me. > > I think if we make an account with no AMQP permissions and the > "monitoring"[0] permission, folks should be able to see everything and > not be able to do anything destructive. Then it's just a question of how > to share the credentials (or just make the account name guest with the > username guest?) and how to expose the management UI port (just require > people to sshuttle?). Could we add a suoders that would let people run these commands as the monitoring user on one of the machines? But then I guess we would have to give shell access, but I like that much better than guest/guest. Thats sure to be abused. Or if we can get a page with this info available at least internally, people could just grab that? I don't think there's anything there we want to keep secret... Would need to run any of these changes by our security officer too. kevin
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
