Topics

Question on reverse proxy's usage

하지훈 <jihun.ha@...>
 

Hi. All,

 

As far as I know, there was a discussion on reverse proxy employment to EdgeX foundry for several security reasons. For that, it is hard for me to know how to apply the reverse proxy to a real edge device, so please let me know the details if anyone is looking on to this.

 

Questions

<Example topology>

Edge device (IP: 10.0.0.2)

 - core service (port: 48080)

 - export-distro service (port: 48070)

 

1. Is it the plan to run a reverse proxy service on every single Edge device? Or, a reverse proxy service is a single entity in a network and is responsible to receive and forward all requests destined to actual services of edge devices inside the network?

 

2. As Nginx and Traefik explained, I understand that services to be proxifed should have different domain names. For example, core.example.com and export.example.com domain names should be used for core service and export service, respectively. Then, should we force to define and use a domain name to a service rather than IP address?

  - Originally, if you want to get data from core service of edge device, you could use "10.0.0.2:48080" address.

  - Releated to Question 1, I think that if reverse proxy service is running on each edge device and we should use domain name to utilize reverse proxy, it sounds impratical. (because Every edge device has to have its own domain name unique in a network)

 

I'd appreciate if you can let me know how to employ a reverse proxy to the above edge device with core and export services?

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

Edge Platform Development | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

Zeng, Tingyu
 

Hey Jihun,

IMO “reverse proxy” refers to an abstract layer, which will be running every single edge device. It might be sitting within each micro service or be part of the process for core data/command/metadata.  The decision hasn’t been finalized.

Nginx and Traefk are using the subdomain as the method to filter and forward to request for proxy. For EdgeX this is just one of the options. Another option is to hook up the http request and intercept the calls within the existing core services.

The reverse proxy needs a way to identify the source of the caller and do authentication/authorization, which needs to be implemented within an Authorization Service.  This was discussed in the current proposal as well.

 

Hope it help.

Tingyu

 

From: edgex-tsc-security-bounces@... [mailto:edgex-tsc-security-bounces@...] On Behalf Of ???
Sent: Tuesday, March 13, 2018 3:40 AM
To: edgex-tsc-security@...
Subject: [Edgex-tsc-security] Question on reverse proxy's usage

 

Hi. All,

 

As far as I know, there was a discussion on reverse proxy employment to EdgeX foundry for several security reasons. For that, it is hard for me to know how to apply the reverse proxy to a real edge device, so please let me know the details if anyone is looking on to this.

 

Questions

<Example topology>

Edge device (IP: 10.0.0.2)

 - core service (port: 48080)

 - export-distro service (port: 48070)

 

1. Is it the plan to run a reverse proxy service on every single Edge device? Or, a reverse proxy service is a single entity in a network and is responsible to receive and forward all requests destined to actual services of edge devices inside the network?

 

2. As Nginx and Traefik explained, I understand that services to be proxifed should have different domain names. For example, core.example.com and export.example.com domain names should be used for core service and export service, respectively. Then, should we force to define and use a domain name to a service rather than IP address?

  - Originally, if you want to get data from core service of edge device, you could use "10.0.0.2:48080" address.

  - Releated to Question 1, I think that if reverse proxy service is running on each edge device and we should use domain name to utilize reverse proxy, it sounds impratical. (because Every edge device has to have its own domain name unique in a network)

 

I'd appreciate if you can let me know how to employ a reverse proxy to the above edge device with core and export services?

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

Edge Platform Development | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

 

하지훈 <jihun.ha@...>
 

Hello. Tingyu.

 

Thank you for answering me. Because of you, I could be clear for that reverse proxy will stand on every edge device and have a role for doing authentication/authorization and forwarding a request to containers behind reverse proxy.

 

Then, I want to ask one more thing: how to configure reverse proxy to hook up all requests sent to inside containers

I think, there are two configurations to operate reverse proxy for multiple containers with regard to their REST APIs

 

Configuration-(A): Expose a same port(e.g. 8080, 443) and define "prefixed" URIs for containers

Configuration-(B): Expose container's exposed ports

 

IMO, Configuration-(B) looks better because containers can use thier own ports and REST APIs without any change even if reverse proxy is employed. On the other side, is there any advantage of Configuration-(A)?? Please let me know the advantage of Configuration-(A)

 

And which configurations is considered in EdgeX?? I know this is not decided, yet, but I want to know some opinion for those configurations.

 

I've remained an explanatory material for Configuration-(A) and (B), below. Hope it help to understand this discussion.

-------

  1. Configuration-(A): Expose a same port(e.g. 8080, 443) and define "prefixed" URIs for containers
    1. Figure
    1. Supported solution: Nginx, Traefik
    2. Pros
      1. Less port on host device is exposed --> More secure
      2. Port conflict problems could be mitigated for multiple containers using same port
        1. More than two containers using same port can be deployed to a single host
    1. Cons
      1. All containers should be distinguished by URIs of containers. To do that, URI prefix should be defined to the containers
        1. EdgeX Core service: <IP>:48098/api/v1  --> <IP>:8080/core-service/api/v1
        2. PROBLEM:  "Prefix" URIs should be pre-defined and agreed to all containers in the device (No use of same prefix URI to two containers)

 

  1. Configuration-(B): Expose container's exposed ports.
    1. Figure
    1. Supported solution: Nginx
    2. Pros
      1. Maintain container's own ports. No need to change REST APIs of containers
    1. Cons
      1. Port conflict problems for two containers could matter.

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

Edge Platform Development | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

--------- Original Message ---------

Sender : Zeng, Tingyu <Tingyu.Zeng@...>

Date : 2018-03-14 07:11 (GMT+9)

Title : RE: [Edgex-tsc-security] Question on reverse proxy's usage

 

Hey Jihun,

IMO “reverse proxy” refers to an abstract layer, which will be running every single edge device. It might be sitting within each micro service or be part of the process for core data/command/metadata.  The decision hasn’t been finalized.

Nginx and Traefk are using the subdomain as the method to filter and forward to request for proxy. For EdgeX this is just one of the options. Another option is to hook up the http request and intercept the calls within the existing core services.

The reverse proxy needs a way to identify the source of the caller and do authentication/authorization, which needs to be implemented within an Authorization Service.  This was discussed in the current proposal as well.

 

Hope it help.

Tingyu

 

From: edgex-tsc-security-bounces@... [mailto:edgex-tsc-security-bounces@...] On Behalf Of ???
Sent: Tuesday, March 13, 2018 3:40 AM
To: edgex-tsc-security@...
Subject: [Edgex-tsc-security] Question on reverse proxy's usage

 

Hi. All,

 

As far as I know, there was a discussion on reverse proxy employment to EdgeX foundry for several security reasons. For that, it is hard for me to know how to apply the reverse proxy to a real edge device, so please let me know the details if anyone is looking on to this.

 

Questions

<Example topology>

Edge device (IP: 10.0.0.2)

 - core service (port: 48080)

 - export-distro service (port: 48070)

 

1. Is it the plan to run a reverse proxy service on every single Edge device? Or, a reverse proxy service is a single entity in a network and is responsible to receive and forward all requests destined to actual services of edge devices inside the network?

 

2. As Nginx and Traefik explained, I understand that services to be proxifed should have different domain names. For example, core.example.com and export.example.com domain names should be used for core service and export service, respectively. Then, should we force to define and use a domain name to a service rather than IP address?

  - Originally, if you want to get data from core service of edge device, you could use "10.0.0.2:48080" address.

  - Releated to Question 1, I think that if reverse proxy service is running on each edge device and we should use domain name to utilize reverse proxy, it sounds impratical. (because Every edge device has to have its own domain name unique in a network)

 

I'd appreciate if you can let me know how to employ a reverse proxy to the above edge device with core and export services?

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

Edge Platform Development | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

 

Zeng, Tingyu
 

Hey Jihun,

As you described bother options have their pros/cons. The biggest issue with config-B is that it will expose multiple ports to the external world, which contradicts the main purpose of putting a reverse proxy between, so we prefer config-A as a better choice currently. Think about down the road for edgex – we may have AAA ( Authentication/Authorization/ AccessControl) features added in to the product so a centralized reverse proxy will single entry point may server better IMHO.

Tingyu

From: edgex-tsc-security-bounces@... [mailto:edgex-tsc-security-bounces@...] On Behalf Of ???
Sent: Tuesday, March 27, 2018 1:15 AM
To: edgex-tsc-security@...
Subject: Re: [Edgex-tsc-security] Question on reverse proxy's usage

 

Hello. Tingyu.

 

Thank you for answering me. Because of you, I could be clear for that reverse proxy will stand on every edge device and have a role for doing authentication/authorization and forwarding a request to containers behind reverse proxy.

 

Then, I want to ask one more thing: how to configure reverse proxy to hook up all requests sent to inside containers

I think, there are two configurations to operate reverse proxy for multiple containers with regard to their REST APIs

 

Configuration-(A): Expose a same port(e.g. 8080, 443) and define "prefixed" URIs for containers

Configuration-(B): Expose container's exposed ports

 

IMO, Configuration-(B) looks better because containers can use thier own ports and REST APIs without any change even if reverse proxy is employed. On the other side, is there any advantage of Configuration-(A)?? Please let me know the advantage of Configuration-(A)

 

And which configurations is considered in EdgeX?? I know this is not decided, yet, but I want to know some opinion for those configurations.

 

I've remained an explanatory material for Configuration-(A) and (B), below. Hope it help to understand this discussion.

-------

1.     Configuration-(A): Expose a same port(e.g. 8080, 443) and define "prefixed" URIs for containers

a.     Figure

                              i.       

b.     Supported solution: Nginx, Traefik

c.     Pros

                              i.        Less port on host device is exposed --> More secure

                             ii.        Port conflict problems could be mitigated for multiple containers using same port

1.     More than two containers using same port can be deployed to a single host

d.     Cons

                              i.        All containers should be distinguished by URIs of containers. To do that, URI prefix should be defined to the containers

1.     EdgeX Core service: <IP>:48098/api/v1  --> <IP>:8080/core-service/api/v1

2.     PROBLEM:  "Prefix" URIs should be pre-defined and agreed to all containers in the device (No use of same prefix URI to two containers)

 

2.     Configuration-(B): Expose container's exposed ports.

a.     Figure

                              i.       

b.     Supported solution: Nginx

c.     Pros

                              i.        Maintain container's own ports. No need to change REST APIs of containers

d.     Cons

                              i.        Port conflict problems for two containers could matter.

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

Edge Platform Development | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

--------- Original Message ---------

Sender : Zeng, Tingyu <Tingyu.Zeng@...>

Date : 2018-03-14 07:11 (GMT+9)

Title : RE: [Edgex-tsc-security] Question on reverse proxy's usage

 

Hey Jihun,

IMO “reverse proxy” refers to an abstract layer, which will be running every single edge device. It might be sitting within each micro service or be part of the process for core data/command/metadata.  The decision hasn’t been finalized.

Nginx and Traefk are using the subdomain as the method to filter and forward to request for proxy. For EdgeX this is just one of the options. Another option is to hook up the http request and intercept the calls within the existing core services.

The reverse proxy needs a way to identify the source of the caller and do authentication/authorization, which needs to be implemented within an Authorization Service.  This was discussed in the current proposal as well.

 

Hope it help.

Tingyu

 

From: edgex-tsc-security-bounces@... [mailto:edgex-tsc-security-bounces@...] On Behalf Of ???
Sent: Tuesday, March 13, 2018 3:40 AM
To: edgex-tsc-security@...
Subject: [Edgex-tsc-security] Question on reverse proxy's usage

 

Hi. All,

 

As far as I know, there was a discussion on reverse proxy employment to EdgeX foundry for several security reasons. For that, it is hard for me to know how to apply the reverse proxy to a real edge device, so please let me know the details if anyone is looking on to this.

 

Questions

<Example topology>

Edge device (IP: 10.0.0.2)

 - core service (port: 48080)

 - export-distro service (port: 48070)

 

1. Is it the plan to run a reverse proxy service on every single Edge device? Or, a reverse proxy service is a single entity in a network and is responsible to receive and forward all requests destined to actual services of edge devices inside the network?

 

2. As Nginx and Traefik explained, I understand that services to be proxifed should have different domain names. For example, core.example.com and export.example.com domain names should be used for core service and export service, respectively. Then, should we force to define and use a domain name to a service rather than IP address?

  - Originally, if you want to get data from core service of edge device, you could use "10.0.0.2:48080" address.

  - Releated to Question 1, I think that if reverse proxy service is running on each edge device and we should use domain name to utilize reverse proxy, it sounds impratical. (because Every edge device has to have its own domain name unique in a network)

 

I'd appreciate if you can let me know how to employ a reverse proxy to the above edge device with core and export services?

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

Edge Platform Development | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

 

 

Jihun Ha <jihun.ha@...>
 

Hi. Tingyu.

 

Thank you for sharing valuable information and your opinion.

BTW, is there any candidate URIs for EdgeX containers where reverse proxy is employed?

For example:

    device service --> http://<host IP>:80/device-service/api/v1/deviceprofile

    notification service --> http://<host IP>:80/nofi-service/api/v1/subscription

 

I'd appreciated if you can let me know :)

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

Edge Platform Development | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

--------- Original Message ---------

Sender : Zeng, Tingyu <Tingyu.Zeng@...>

Date : 2018-03-29 04:57 (GMT+9)

Title : RE: [Edgex-tsc-security] Question on reverse proxy's usage

 

Hey Jihun,

As you described bother options have their pros/cons. The biggest issue with config-B is that it will expose multiple ports to the external world, which contradicts the main purpose of putting a reverse proxy between, so we prefer config-A as a better choice currently. Think about down the road for edgex – we may have AAA ( Authentication/Authorization/ AccessControl) features added in to the product so a centralized reverse proxy will single entry point may server better IMHO.

Tingyu

From: edgex-tsc-security-bounces@... [mailto:edgex-tsc-security-bounces@...] On Behalf Of ???
Sent: Tuesday, March 27, 2018 1:15 AM
To: edgex-tsc-security@...
Subject: Re: [Edgex-tsc-security] Question on reverse proxy's usage

 

Hello. Tingyu.

 

Thank you for answering me. Because of you, I could be clear for that reverse proxy will stand on every edge device and have a role for doing authentication/authorization and forwarding a request to containers behind reverse proxy.

 

Then, I want to ask one more thing: how to configure reverse proxy to hook up all requests sent to inside containers

I think, there are two configurations to operate reverse proxy for multiple containers with regard to their REST APIs

 

Configuration-(A): Expose a same port(e.g. 8080, 443) and define "prefixed" URIs for containers

Configuration-(B): Expose container's exposed ports

 

IMO, Configuration-(B) looks better because containers can use thier own ports and REST APIs without any change even if reverse proxy is employed. On the other side, is there any advantage of Configuration-(A)?? Please let me know the advantage of Configuration-(A)

 

And which configurations is considered in EdgeX?? I know this is not decided, yet, but I want to know some opinion for those configurations.

 

I've remained an explanatory material for Configuration-(A) and (B), below. Hope it help to understand this discussion.

-------

1.     Configuration-(A): Expose a same port(e.g. 8080, 443) and define "prefixed" URIs for containers

a.     Figure

                              i.       

b.     Supported solution: Nginx, Traefik

c.     Pros

                              i.        Less port on host device is exposed --> More secure

                             ii.        Port conflict problems could be mitigated for multiple containers using same port

1.     More than two containers using same port can be deployed to a single host

d.     Cons

                              i.        All containers should be distinguished by URIs of containers. To do that, URI prefix should be defined to the containers

1.     EdgeX Core service: <IP>:48098/api/v1  --> <IP>:8080/core-service/api/v1

2.     PROBLEM:  "Prefix" URIs should be pre-defined and agreed to all containers in the device (No use of same prefix URI to two containers)

 

2.     Configuration-(B): Expose container's exposed ports.

a.     Figure

                              i.       

b.     Supported solution: Nginx

c.     Pros

                              i.        Maintain container's own ports. No need to change REST APIs of containers

d.     Cons

                              i.        Port conflict problems for two containers could matter.

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

Edge Platform Development | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

--------- Original Message ---------

Sender : Zeng, Tingyu <Tingyu.Zeng@...>

Date : 2018-03-14 07:11 (GMT+9)

Title : RE: [Edgex-tsc-security] Question on reverse proxy's usage

 

Hey Jihun,

IMO “reverse proxy” refers to an abstract layer, which will be running every single edge device. It might be sitting within each micro service or be part of the process for core data/command/metadata.  The decision hasn’t been finalized.

Nginx and Traefk are using the subdomain as the method to filter and forward to request for proxy. For EdgeX this is just one of the options. Another option is to hook up the http request and intercept the calls within the existing core services.

The reverse proxy needs a way to identify the source of the caller and do authentication/authorization, which needs to be implemented within an Authorization Service.  This was discussed in the current proposal as well.

 

Hope it help.

Tingyu

 

From: edgex-tsc-security-bounces@... [mailto:edgex-tsc-security-bounces@...] On Behalf Of ???
Sent: Tuesday, March 13, 2018 3:40 AM
To: edgex-tsc-security@...
Subject: [Edgex-tsc-security] Question on reverse proxy's usage

 

Hi. All,

 

As far as I know, there was a discussion on reverse proxy employment to EdgeX foundry for several security reasons. For that, it is hard for me to know how to apply the reverse proxy to a real edge device, so please let me know the details if anyone is looking on to this.

 

Questions

<Example topology>

Edge device (IP: 10.0.0.2)

 - core service (port: 48080)

 - export-distro service (port: 48070)

 

1. Is it the plan to run a reverse proxy service on every single Edge device? Or, a reverse proxy service is a single entity in a network and is responsible to receive and forward all requests destined to actual services of edge devices inside the network?

 

2. As Nginx and Traefik explained, I understand that services to be proxifed should have different domain names. For example, core.example.com and export.example.com domain names should be used for core service and export service, respectively. Then, should we force to define and use a domain name to a service rather than IP address?

  - Originally, if you want to get data from core service of edge device, you could use "10.0.0.2:48080" address.

  - Releated to Question 1, I think that if reverse proxy service is running on each edge device and we should use domain name to utilize reverse proxy, it sounds impratical. (because Every edge device has to have its own domain name unique in a network)

 

I'd appreciate if you can let me know how to employ a reverse proxy to the above edge device with core and export services?

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

Edge Platform Development | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

 

 

Zeng, Tingyu
 

The decision hasn’t been made but the community is leaning towards using the individual existing micro service name of the EdgeX as short partial url, just like the example mentioned in your email.

One thing we need to pay attention when choosing the proper partial url is to avoid using special characters in the url due to two reasons.

1.       The special characters needs to be encoded in the URL when passing around.

2.       The special characters are risky in url and query string from security perspective, mainly because of the potential XSS vulnerability.

 

Thanks,

Tingyu

From: EdgeX-TSC-Security@... [mailto:EdgeX-TSC-Security@...] On Behalf Of Jihun Ha
Sent: Tuesday, April 3, 2018 10:53 PM
To: EdgeX-TSC-Security@...
Subject: Re: [Edgex-tsc-security] Question on reverse proxy's usage

 

Hi. Tingyu.

 

Thank you for sharing valuable information and your opinion.

BTW, is there any candidate URIs for EdgeX containers where reverse proxy is employed?

For example:

    device service --> http://<host IP>:80/device-service/api/v1/deviceprofile

    notification service --> http://<host IP>:80/nofi-service/api/v1/subscription

 

I'd appreciated if you can let me know :)

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

Edge Platform Development | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

--------- Original Message ---------

Sender : Zeng, Tingyu <Tingyu.Zeng@...>

Date : 2018-03-29 04:57 (GMT+9)

Title : RE: [Edgex-tsc-security] Question on reverse proxy's usage

 

Hey Jihun,

As you described bother options have their pros/cons. The biggest issue with config-B is that it will expose multiple ports to the external world, which contradicts the main purpose of putting a reverse proxy between, so we prefer config-A as a better choice currently. Think about down the road for edgex – we may have AAA ( Authentication/Authorization/ AccessControl) features added in to the product so a centralized reverse proxy will single entry point may server better IMHO.

Tingyu

From: edgex-tsc-security-bounces@... [mailto:edgex-tsc-security-bounces@...] On Behalf Of ???
Sent: Tuesday, March 27, 2018 1:15 AM
To: edgex-tsc-security@...
Subject: Re: [Edgex-tsc-security] Question on reverse proxy's usage

 

Hello. Tingyu.

 

Thank you for answering me. Because of you, I could be clear for that reverse proxy will stand on every edge device and have a role for doing authentication/authorization and forwarding a request to containers behind reverse proxy.

 

Then, I want to ask one more thing: how to configure reverse proxy to hook up all requests sent to inside containers

I think, there are two configurations to operate reverse proxy for multiple containers with regard to their REST APIs

 

Configuration-(A): Expose a same port(e.g. 8080, 443) and define "prefixed" URIs for containers

Configuration-(B): Expose container's exposed ports

 

IMO, Configuration-(B) looks better because containers can use thier own ports and REST APIs without any change even if reverse proxy is employed. On the other side, is there any advantage of Configuration-(A)?? Please let me know the advantage of Configuration-(A)

 

And which configurations is considered in EdgeX?? I know this is not decided, yet, but I want to know some opinion for those configurations.

 

I've remained an explanatory material for Configuration-(A) and (B), below. Hope it help to understand this discussion.

-------

1.     Configuration-(A): Expose a same port(e.g. 8080, 443) and define "prefixed" URIs for containers

a.     Figure

                              i.       

b.     Supported solution: Nginx, Traefik

c.     Pros

                              i.        Less port on host device is exposed --> More secure

                             ii.        Port conflict problems could be mitigated for multiple containers using same port

1.     More than two containers using same port can be deployed to a single host

d.     Cons

                              i.        All containers should be distinguished by URIs of containers. To do that, URI prefix should be defined to the containers

1.     EdgeX Core service: <IP>:48098/api/v1  --> <IP>:8080/core-service/api/v1

2.     PROBLEM:  "Prefix" URIs should be pre-defined and agreed to all containers in the device (No use of same prefix URI to two containers)

 

2.     Configuration-(B): Expose container's exposed ports.

a.     Figure

                              i.       

b.     Supported solution: Nginx

c.     Pros

                              i.        Maintain container's own ports. No need to change REST APIs of containers

d.     Cons

                              i.        Port conflict problems for two containers could matter.

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

Edge Platform Development | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com

 

 

--------- Original Message ---------

Sender : Zeng, Tingyu <Tingyu.Zeng@...>

Date : 2018-03-14 07:11 (GMT+9)

Title : RE: [Edgex-tsc-security] Question on reverse proxy's usage

 

Hey Jihun,

IMO “reverse proxy” refers to an abstract layer, which will be running every single edge device. It might be sitting within each micro service or be part of the process for core data/command/metadata.  The decision hasn’t been finalized.

Nginx and Traefk are using the subdomain as the method to filter and forward to request for proxy. For EdgeX this is just one of the options. Another option is to hook up the http request and intercept the calls within the existing core services.

The reverse proxy needs a way to identify the source of the caller and do authentication/authorization, which needs to be implemented within an Authorization Service.  This was discussed in the current proposal as well.

 

Hope it help.

Tingyu

 

From: edgex-tsc-security-bounces@... [mailto:edgex-tsc-security-bounces@...] On Behalf Of ???
Sent: Tuesday, March 13, 2018 3:40 AM
To: edgex-tsc-security@...
Subject: [Edgex-tsc-security] Question on reverse proxy's usage

 

Hi. All,

 

As far as I know, there was a discussion on reverse proxy employment to EdgeX foundry for several security reasons. For that, it is hard for me to know how to apply the reverse proxy to a real edge device, so please let me know the details if anyone is looking on to this.

 

Questions

<Example topology>

Edge device (IP: 10.0.0.2)

 - core service (port: 48080)

 - export-distro service (port: 48070)

 

1. Is it the plan to run a reverse proxy service on every single Edge device? Or, a reverse proxy service is a single entity in a network and is responsible to receive and forward all requests destined to actual services of edge devices inside the network?

 

2. As Nginx and Traefik explained, I understand that services to be proxifed should have different domain names. For example, core.example.com and export.example.com domain names should be used for core service and export service, respectively. Then, should we force to define and use a domain name to a service rather than IP address?

  - Originally, if you want to get data from core service of edge device, you could use "10.0.0.2:48080" address.

  - Releated to Question 1, I think that if reverse proxy service is running on each edge device and we should use domain name to utilize reverse proxy, it sounds impratical. (because Every edge device has to have its own domain name unique in a network)

 

I'd appreciate if you can let me know how to employ a reverse proxy to the above edge device with core and export services?

 

Best Regards,

 

Jihun Ha (하지훈/河志薰, Ph.D.)

Edge Platform Development | IoT Lab

Software R&D Center | Samsung Electronics Co., Ltd

Mobile +82 10 2533 7947

jihun.ha at samsung.com | jhha85 at gmail.com