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 ? > > 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 . 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
