Thank you guys for your responses. What bothers me is that such an Edge router placed at the client will have all the topology information about every single other router in the network, how they are interconnected, etc., as it has to participate in the routing data exchange. It will even expose the Qpid console! Will show network throughput, etc. Some data a client should have no access to imo.
Some of these clients in our case might have intermittent connections over weak links, and there could be quite a few of them (i.e. several thousands clients). So this routing information would have to be exchanged every time a client's Edge router connects to the core network. Do you have any ideas how to mitigate this or maybe this shouldn't actually deserve any serious concerns? Thank you. -----Original Message----- From: Chuck Rolke <cro...@redhat.com> Sent: vrijdag 20 november 2020 17:57 To: users@qpid.apache.org Subject: Re: Edge router on the client side Also, do not build the image with certificates embedded within it. Find a way to inject the connection secrets into the container as it is launched. ----- Original Message ----- > From: "Ted Ross" <tr...@redhat.com> > To: users@qpid.apache.org > Sent: Friday, November 20, 2020 10:53:45 AM > Subject: Re: Edge router on the client side > > On Fri, Nov 20, 2020 at 5:32 AM Petrenko, Vadim <vadim.petre...@ns.nl> > wrote: > > > Hi Qpid developers, > > > > We’re considering this possibility: > > > > Containerize a preconfigured Edge router (possibly together with Artemis) > > and give it to an application team. > > > > The application team will then deploy this container in their environment > > -> the Edge router will connect to a couple Interior routers in our Core > > network -> the client application will connect to the Edge router in the > > container using standard libraries like Qpid-JMS. > > > > We expect this to allow easy scaling up of clients. We also want to attach > > a broker to the edge router in case messages need to be buffered (but this > > is client specific and does not belong to the generic core network setup). > > > > Does this setup look reasonable from a Qpid developer’s point of view? > > Maybe there are some pitfalls to watch out for? Especially exposing > > Interior routers to the world. > > > > This is a good use case, and one that I think is appropriate for edge > routers. > > If you are going to deploy your interior routers in a public place, I think > you would want strong security (mutual TLS) on those open ports. Can you > issue certificates to your application teams in the form of secrets so they > can securely connect to your network? > > > > > > > > Thanks! > > > > > > > > ________________________________ > > > > Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor > > (gebruik door) de geadresseerde. De e-mail kan persoonlijke of > > vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging, > > verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en > > eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan. Indien u > > niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht degene > > die de e-mail verzond hiervan direct op de hoogte te brengen en de e-mail > > (en eventuele bijlagen) te vernietigen. > > > > Informatie vennootschap<http://www.ns.nl/emaildisclaimer> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > > For additional commands, e-mail: users-h...@qpid.apache.org > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org ________________________________ Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor (gebruik door) de geadresseerde. De e-mail kan persoonlijke of vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan. Indien u niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht degene die de e-mail verzond hiervan direct op de hoogte te brengen en de e-mail (en eventuele bijlagen) te vernietigen. Informatie vennootschap<http://www.ns.nl/emaildisclaimer> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
