I'm assuming you're considering the solution where we have a single broker and we make it publicly accessible (option 1). > how easy would it be to turn off the possibility for external > publisher to flood the broker ? External clients won't publish anything, they'll be read-only (with a few exceptions like the CentOS CI folks). However they can create a huge amount of queues, subscribe to everything and never consume anything. We can mitigate that by setting up another vhost (in the cluster we already have) for external clients, limit the number of queues on that vhost, and enforce a time to live on messages in the queues. It'll require some fine tuning, though, and external clients will still be able to DoS other external clients if we don't do authentication (option A). I value option 2 (separate broker) higher than option 1 (same broker) because I'm not entirely sure those limits can prevent any kind of DoS on the broker. Attackers are creative. It's easier to make sure the resources used by a 2nd cluster don't impact the resources of the 1st cluster. > Can we configure the queues that are critical to have higher > priority to the external ones ? Yes, by using a different vhost for internal (and CentOS) stuff and external stuff, and replicating messages from the internal to the external vhost. > If we have on public broker with authentication can we easily kill the accounts that are flooding us ? Yes, that's the main advantage of option B. > What are the consequences of the service been down ? What is an > acceptable down time 1 min, 1h , 1 day , 1 week, 1 month ? I would say that the internal messaging service needs a high availability, while the SLA for the external service can be lower. That's also a reason for me prefering option 2. I hope that clarifies a bit. 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
