On Mon, Nov 23, 2020 at 7:37 AM Petrenko, Vadim <vadim.petre...@ns.nl> wrote:
> 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. > When the edge router connects to a router network (to an interior router), the router network thinks of the edge router as just just another client albeit a "special" client. The edge router itself is not part of the network. Whenever a qdstat client asks the edge router for the topology of the router network, it in turn asks the interior it is connected to for that information. That being said, I wonder if you can use some policy restrictions on the interior router to block all management requests (requests to $management address) coming from the edge router (I would let the policy experts weigh in on this). This would effectively block the edge router from accessing any sensitive information about the router network but still allowing qdstat/qdmanage to work within the context of the edge router. > > 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 > >
