On Wed, 27 Feb 2019 at 05:17, Clement Verna <cverna@xxxxxxxxxxxxxxxxx> wrote: > > On Wed, 27 Feb 2019 at 10:57, Aurelien Bompard > <abompard@xxxxxxxxxxxxxxxxx> wrote: > > > > Hey y'all, > > > > Fedora Messaging, the replacement for fedmsg, is using AMQP and thus a > > message broker. The current clusters we have deployed in staging and > > prod are only accessible from inside our infrastructure. > > There are two needs for an externally accessible broker: > > - the CentOS folks, who are outside of our infrastructure, would like > > to send messages > > - people from the community would like to subscribe to messages and do > > things based on them > > > > We have several options to make that happen. > > > > 1. Use our existing cluster and expose it to the world > > The advantage is we don't maintain another cluster, but the downside > > is in the case of a DoS attack we're directly affected. With RabbitMQ > > 3.7 there are some limits[0] you can set on vhosts (max connections > > and max queues), but we're not yet on 3.7. > > [0] https://www.rabbitmq.com/vhosts.html#limits > > What would it take to get 3.7 ? Could we react (shuting down the > queues ? ) to DoS early with monitoring ? What would it take for > someone to DoS our cluster, basically how easy would it be ? > I expect that even with 3.7 the limits just make it so we don't shut down but find anything relying on messaging aren't working. So if gating, bodhi, pkgs relies on messages from fedora-messaging ot do tasks.. we are basically not working until the DoS is over. > > > > 2. Use a separate cluster and copy messages over > > We could deploy a separate cluster that would get a copy of all > > messages, and would be more limited in resources. It truly isolates > > infrastructure, so it's better protected against DoS, but it's more > > work for sysadmins. > > > > In both cases, there are several paths we can take as regards to authentication. > > > > A: make a single readonly account for everybody in the community to > > use, and a few read-write accounts (with X509 certs) for people who > > need to publish, ie CentOS CI. If we choose a separate broker we can > > copy those messages back to the main cluster. > > The issue here is that everybody in the community will be using the > > same account, so it's harder to shut down bad actors. It would also be > > theoretically possible for someone to consume from somebody else's > > queue (unless people make sure they use UUIDs in queues, I think we > > can enforce that but it way have side effects). > > However, it enables the same kind of usage that fedmsg provided before. > > > > B: require authentication with username & password but make it easy to > > get accounts. People could require accounts via tickets for example. > > It will make it much harder to abuse the service, and we could easily > > shut down bad actors. However it's an obviously heavier load on the > > people who will handle the tickets and create the accounts. > > > > My personal preference would be option 2A, so an external broker with > > an anonymous read-only account, but all combinations of options > > inflict different loads on the sysadmin (on deployment and in the > > longer term), so I think it's really up to them. > > > > What do you guys think? > > I am generally not a fan of creating more work for hypothetical DoS, I > my opinion we should try to mitigate as much as possible to effect of > a possible DoS . > I can say that there are quite a few people out there who look for someone uttering "hypothetical DoS" to prove to them one will exist. So now that you have done so.. we should assume we will have one and plan on how to deal with. > Just my 0.02 $ since I have very little knowledge about RabbitMQ ;-) > > > > > Thanks > > Aurélien > > _______________________________________________ > > infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ > infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx -- Stephen J Smoogen. _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
