You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by "Petrenko, Vadim" <va...@ns.nl> on 2020/11/20 10:27:19 UTC
Edge router on the client side
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.
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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Edge router on the client side
Posted by Ken Giusti <kg...@redhat.com>.
On Mon, Nov 23, 2020 at 7:32 AM Petrenko, Vadim <va...@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.
>
> Do you have any ideas how to mitigate this or maybe this shouldn't
> actually deserve any serious concerns?
>
>
Actually, the edge routers do not fully participate in the route table
exchange. Edge routers are exposed to only those addresses needed by the
clients attached to the edge itself. Specifically, when a subscriber
client attaches to the edge, the edge notifies its attached interior router
of the subscription address and leaves it to the interior router to
propagate that on behalf of the edge router. Similar behavior for
producing clients - the edge queries its interior router for route details
for only the producer's destination address.
So the amount of routing information that needs to be exchanged between the
edge and its interior is minimal and probably is not something to be
concerned about.
-K
> Thank you.
>
> -----Original Message-----
> From: Chuck Rolke <cr...@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 <va...@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-unsubscribe@qpid.apache.org
> > > For additional commands, e-mail: users-help@qpid.apache.org
> > >
> > >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
--
-K
Re: Edge router on the client side
Posted by Chuck Rolke <cr...@redhat.com>.
----- Original Message -----
> From: "Ganesh Murthy" <gm...@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 <va...@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 <cr...@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 <va...@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-unsubscribe@qpid.apache.org
> > > > For additional commands, e-mail: users-help@qpid.apache.org
> > > >
> > > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@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-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Edge router on the client side
Posted by Ganesh Murthy <gm...@redhat.com>.
On Mon, Nov 23, 2020 at 7:37 AM Petrenko, Vadim <va...@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 <cr...@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 <va...@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-unsubscribe@qpid.apache.org
> > > For additional commands, e-mail: users-help@qpid.apache.org
> > >
> > >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
RE: Edge router on the client side
Posted by "Petrenko, Vadim" <va...@ns.nl>.
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 <cr...@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 <va...@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-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Edge router on the client side
Posted by Chuck Rolke <cr...@redhat.com>.
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 <va...@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-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Edge router on the client side
Posted by Ted Ross <tr...@redhat.com>.
On Fri, Nov 20, 2020 at 5:32 AM Petrenko, Vadim <va...@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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>