----- Original Message -----
> From: "Ganesh Murthy" <gmur...@redhat.com>
> To: users@qpid.apache.org
> Sent: Monday, November 23, 2020 9:22:02 AM
> Subject: Re: Edge router on the client side
>
> 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.
Using policy to restrict what address to which a client is allowed to read
or to write is most definitely an option. See
https://qpid.apache.org/releases/qpid-dispatch-1.14.0/user-guide/index.html#vhost-policy-examples-qdr
Policy can also restrict the number of connections a user may have
simultaneously,
maximum message size, and other resource limits.
https://qpid.apache.org/releases/qpid-dispatch-1.14.0/user-guide/index.html#configuring-authorization-qdr
>
> >
> > 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
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
