Re: 回复: [edgex-tsc-ui] 回复: EdgeX UI PR #138

Michael Estrin <m.estrin@...>
 

For what it is worth, securing internal communications is on the security road map for the Hanoi release.  


They have created a related issue to cover this enhancement:  https://github.com/edgexfoundry/edgex-go/issues/1950  


The Security Working Group (https://wiki.edgexfoundry.org/display/FA/Security+Working+Group) is the proper forum for providing feedback on the proposed approach.



From: Conn, Trevor
Sent: Friday, December 20, 2019 9:54 AM
To: Zhang, Huaqiao (c); Jim White; Estrin, Michael
Cc: EdgeX-TSC-UI@...
Subject: RE: 回复: [edgex-tsc-ui] 回复: EdgeX UI PR #138
 

Hi Huaqiao – Yes, we understand. In fact, the diagram below is the exact deployment topology we had for our demo that necessitated PR #138. In our case the VMWare OneCloud load balancer is standing in for the “API Gateway Service”.

 

Trevor

 

From: EdgeX-TSC-UI@... <EdgeX-TSC-UI@...> On Behalf Of huaqiaoz via Lists.Edgexfoundry.Org
Sent: Thursday, December 19, 2019 10:57 PM
To: Jim White; Estrin, Michael
Cc: EdgeX-TSC-UI@...
Subject:
回复: 回复: [edgex-tsc-ui] 回复: EdgeX UI PR #138

 

[EXTERNAL EMAIL]

Hi All.

 

Maybe i was not clear enough as I described it earlier.

So i made a draft to show the location of web UI and how UI agents request to access to edgex behind api-gateway.

 

 

 


发件人: Huaqiao Zhang (c) <huaqiaoz@...>
发送时间: 20191220 10:46
收件人: Jim White <jim@...>; Estrin, Michael (EMC) <M_Estrin@...>
抄送: Cloud Tsai <cloud@...>; EdgeX-TSC-UI@... <EdgeX-TSC-UI@...>; Jason.Bonafide@... <Jason.Bonafide@...>; Conn, Trevor (EMC) <Trevor_Conn@...>; Zeng, Tingyu (EMC) <Tingyu.Zeng@...>
主题: 回复: [edgex-tsc-ui] 回复: EdgeX UI PR #138

 

I agree with Jim

 

In the current situation, I do not recommend that UI access edgex via api-gateway, for the reasons I mentioned earlier, and because in the current situation, the UI doesn't have the ability to run in production, it's a heavy workload.

 

However, I still recommend improving the way how to retrieve the authorization token by providing remote authentication login interface, not only just CLI.

 

Thanks

huaqiao

 

 


发件人: Jim White <jim@...>
发送时间: 20191220 0:21
收件人: Estrin, Michael (EMC) <M_Estrin@...>
抄送: Cloud Tsai <cloud@...>; Huaqiao Zhang (c) <huaqiaoz@...>; EdgeX-TSC-UI@... <EdgeX-TSC-UI@...>; Jason.Bonafide@... <Jason.Bonafide@...>; Conn, Trevor (EMC) <Trevor_Conn@...>; Zeng, Tingyu (EMC) <Tingyu.Zeng@...>
主题: Re: [edgex-tsc-ui] 回复: EdgeX UI PR #138

 

Michael, Cloud and all...

 

On the matter of whether the UI is inside or outside of the Kong firewall...

We have, to date, considered the UI as a means to support demos and development - and therefore "inside" of the Kong API gateway.  Or more precisely, since demos and development are not often done with security turned on, the UI would be used with an unprotected version of EdgeX.

 

Part of the reason for this was due to two issues:

a) security - precisely the complexities of how the UI would pierce the API gateway

b) distributed nature - what happens when the services start to live on different boxes.

 

Not that these issues are not insurmountable, it just wasn't something we wanted to put a lot of time on given the nature of what the UI was being used for.

 

So if we, as a community, now think that the UI is going to be used in more production level use cases, we need to re-address this larger question.  I will say that one of the value adds we held out for company's like my own to offer up was the more production level UIs, dashboards, and tooling.  So if we decide to take this on in the project, we need some community involvement in this decision and recognize we are looking at the UI as more of a central offering of the project.

 

I recommend we keep the UI a demo/internal tool for now (as it has been) and we tee this up with the architecture and TSC meetings in the new year.  In other words, the UI offered as part of the open source either operate without security or operate inside of the Kong Gateway.

 

 

Jim White

CTO, IOTech

EdgeX Foundry co-founder & TSC Vice-chairman

On EdgeX Slack @ jpwhite

612-916-6693

 

 

On Thu, 19 Dec 2019 at 07:29, <M.Estrin@...> wrote:

Thank you for clarifying.

 

As I said before, there's a basic design decision to be made on which side of Kong the UI backend will reside.

 

If outside, the UI backend would be considered external to the EdgeX installation and should be required to communicate with the EdgeX services via Kong (i.e. the same as any other northside service).

 

If inside, the UI backend would be considered internal to the EdgeX installation and should communicate with the EdgeX services directly regardless of where the services reside.  I believe the Security Working Group has plans to harden internal EdgeX service-to-service communication in the future road map.  In this scenario, the UI backend would need to be hardened along with every other internal EdgeX service.  I would expect service-to-service communication changes to be limited to go-mod-core-contracts.  That is, I'd expect the UI backend to use go-mod-core-contracts as it exists today to communicate with individual services.  This would limit future rework required to accommodate security-related changes.

 

I think the key thing I want to communicate in response is that -- from my perspective -- a UI backend that's internal to the EdgeX installation should communicate with EdgeX services directly even in a distributed environment.  Securing these service-to-service communication channels is on the security road map.

 

Having said that, I realize now that I don't have a clear understanding of the security boundary around EdgeX in a truly distributed environment.  I don't know if the Security Working Group has given this any consideration -- and if they have what the outcome was.  I would think the answer to that question is a necessary prerequisite to evaluating your proposed solution and my response to it.

 

Perhaps someone from security could join the discussion and/or this could be raised as a topic within the Security Working Group...?

 


From: Cloud Tsai <cloud@...>
Sent: Thursday, December 19, 2019 8:14 AM
To: Estrin, Michael
Cc: Zhang, Huaqiao (c); EdgeX-TSC-UI@...; Jim White; Bonafide, Jason; Conn, Trevor; Zeng, Tingyu
Subject: Re: [edgex-tsc-ui]
回复: EdgeX UI PR #138

 

[EXTERNAL EMAIL]

Hi Michael,

 

Sorry for the unclear statement.  Let me try to explain my idea in an example.

Here is the device client initialization code snippet

mdc = metadata.NewDeviceClient(
  
types.EndpointParams{
     
ServiceKeyclients.CoreMetaDataServiceKey,
     
Path:        clients.ApiDeviceRoute,
     
UseRegistry: registryClient != nil,
     
Url:         Configuration.Clients["Metadata"].Url() + clients.ApiDeviceRoute,
     
Interval:    Configuration.Service.ClientMonitor,
   },
  
endpoint.Endpoint{RegistryClient: &registryClient})

It only allows HTTP communication now, and my idea is to add some security related parameters into EndpointParams, such as token.

Then, the UI backend can use DeviceClient to communicate with Core Metadata through HTTPS.

In a distributed environment, the service to service interaction might go through different API Gateways on machines.

It's just a thought, and I can help the design and implementation if you and Trevor agree with this direction.

 

 

On Thu, 19 Dec 2019 at 21:21, <M.Estrin@...> wrote:

I'm not sure what you're proposing for changes to the client code of go-mod-core-contract.

 

There's a basic design decision to be made on which side of Kong the UI backend will reside.

 

If outside, the UI backend would be considered external to the EdgeX installation and should be required to communicate with the EdgeX services via Kong (i.e. the same as any other northside service).

 

If inside, the UI backend would be considered internal to the EdgeX installation and should communicate with the EdgeX services directly regardless of where the services reside.  I believe the Security Working Group has plans to harden internal EdgeX service-to-service communication in the future road map.  In this scenario, the UI backend would need to be hardened along with every other internal EdgeX service.  I would expect service-to-service communication changes to be limited to go-mod-core-contracts.  That is, I'd expect the UI backend to use go-mod-core-contracts as it exists today to communicate with individual services.  This would limit future rework required to accommodate security-related changes.

 


From: Cloud Tsai <cloud@...>
Sent: Thursday, December 19, 2019 7:02 AM
To: Estrin, Michael; Conn, Trevor; Zeng, Tingyu
Cc: Zhang, Huaqiao (c); EdgeX-TSC-UI@...; Jim White; Bonafide, Jason
Subject: Re: [edgex-tsc-ui]
回复: EdgeX UI PR #138

 

[EXTERNAL EMAIL]

Hi Trevor, Michael, and Tingyu,

 

About calling services via API Gateway, I thought we had better make some implementation in the client code of go-mod-core-contract.

The UI backend is implemented in Golang, so it should be able to leverage the client code of go-mod-core-contract.

We could give some security related parameters when initializing the clients, and they would become to communicate with other services through API Gateway.

This would also be helpful for the distributed environment.  For example, deploying core-data and core-metadata on different machines and they are all protected by an API Gateway on individual machines.

What do you think?

 

On Thu, 19 Dec 2019 at 20:44, Michael Estrin <m.estrin@...> wrote:

+ Jason Bonafide

 


From: EdgeX-TSC-UI@... <EdgeX-TSC-UI@...> on behalf of huaqiaoz via Lists.Edgexfoundry.Org <huaqiaoz=vmware.com@...>
Sent: Thursday, December 19, 2019 5:18 AM
To: Jim White
Cc: EdgeX-TSC-UI@...
Subject: [edgex-tsc-ui]
回复: EdgeX UI PR #138

 

[EXTERNAL EMAIL]

HI all

 

About how UI agents request access to the edgex service behind api-gateway

 

we should know a few things:

  • If the user uses the api-gateway service (actually it is kong and vault), access authorization authentication is enabled.
  • If we want UI to agent any requests to access edgex behind api-gateway service, a valid access token is required
  • Once the UI adapts the api-gateway, the user must start the api-gateway service when the user uses the UI 

 

In order to do this, we need to do or solve the following problems:

  • Remove gateway tab on the UI menu, there is no term "gateway" any more.
  • UI backend server needs to access to edgex-api-gateway service and retrieves the access token, but there is no remote apis to communicate with api-gateway service, the access token can only be got by CLI.
  • The user's registration also cannot be associated with a specific valid access token,because user additions also require the command line of the api-gateway service
  • If the user starts edgex with source code, the UI cannot be used anymore because kong and vault can only be in container now.

 

So I think api-gateway is needed to provide remote apis so that the UI can get access tokens at run time.

 

Thanks

huaqiao

 


发件人: Jim White <jim@...>
发送时间: 20191214 4:11
收件人: Huaqiao Zhang (c) <huaqiaoz@...>
抄送: Gavin Lu <gguanglu@...>; Conn, Trevor (EMC) <Trevor_Conn@...>; Jason Bonafide <jbonafide623@...>; Tiejun Chen <tiejunc@...>; Jason Bonafide <jason_bonafide@...>; edgex-tsc-ui@... <edgex-tsc-ui@...>
主题: Re: EdgeX UI PR #138

 

forwarding this message to the UI forum for historical tracking and record of any decisions off this thread.

 

I recommend we take this up as part of the discussion in the next UI project meeting.

 

The EdgeX UI was created as a kind of tool for conference demos and simple UI for developers.  I don't know that it will ever be used as a production grade interface without a lot more effort.  We can let the current UI team (led by Gavin) tell us if they have the resources to spend to make it something that can be used with the API gateway (either now or in the future).  And load balancers and enterprise level issues are not something we are addressing much in any part of EdgeX yet - so I have concerns about trying to drag the entire project in that direction without some overarching coordination and timing from the community on that.

 

Priority of effort for Geneva release in my opinion should be:

a) addressing the EdgeX API changes in the UI

b) addressing the new types of services that the API does not support yet (namely the application services, system management, and potentially new rules engine)

c) insuring the UI is made aware of new sensors that are auto provisioned

 

Beyond that, there are lots of directions we could take such as better HA support, managing multiple instances, better dashboarding and display of the sensor data, etc. but I view that as future roadmap release items unless we have more resources to throw at the development needs in this area. 

 

Jim White

CTO, IOTech

EdgeX Foundry co-founder & TSC Vice-chairman

On EdgeX Slack @ jpwhite

612-916-6693

 

 

On Thu, 12 Dec 2019 at 21:57, Huaqiao Zhang (c) <huaqiaoz@...> wrote:

Hi all.

 

And Jason Bonafide

 

I know what you want, you want to call the APIs of all microservices through the API gateway , but if you modify it this way will affect the previous code if user not using API gateway service, i did't test it whether it will cause other functions not work.

 

My suggestion is that you should know how API gateway agent the http requests firstly, if you know it well, you will find this UI server based on the principle of API gateway, why? because there is no API gateway project when UI project was released. So, edgex-ui-go has to some extent taken on the role of an api-getway back-end service.

 

so i think there are two ways to solve the problem:

 

Firstly, based on microservices architecture principle, all microservices architecture projects should have an api-gateway service , so update Edgex-ui-go adapted to API-getway microservice, then users must start API-gateway microservice when users use edgex foundry.

 

Secondly, to update the UI coding logic, the basic idea is to add the default statement to the switch-case statement, to add the api-gatway path, but I haven't figured that out yet!

 

Thanks

huaqiao


发件人: Gavin Lu <gguanglu@...>
发送时间: 20191213 10:52
收件人: Conn, Trevor (EMC) <Trevor_Conn@...>; Jason Bonafide <jbonafide623@...>; Huaqiao Zhang (c) <huaqiaoz@...>; Tiejun Chen <tiejunc@...>
抄送: Jason Bonafide <jason_bonafide@...>; Jim White <jim@...>
主题: Re: EdgeX UI PR #138

 

Do you mean https://github.com/edgexfoundry/edgex-ui-go/commit/c4ab4ee6800c96e0911320ddc65eaff7ac622bce ?

 

I see that’s reverted by Tiejun & Huaqiao.

 

Tiejun/Huaqiao, could either of you provide comments in the page? So we could elaborate more details and collaborate easier.

 

Thanks,

 

Gavin

 

From: "Conn, Trevor" <Trevor_Conn@...>
Date: Friday, December 13, 2019 at 2:25 AM
To: Jason Bonafide <jbonafide623@...>, "Huaqiao Zhang (c)" <huaqiaoz@...>, Tiejun Chen <tiejunc@...>, Gavin Lu <gguanglu@...>
Cc: Jason Bonafide <jason_bonafide@...>, Jim White <jim@...>
Subject: RE: EdgeX UI PR #138

 

+ Gavin

 

I’m not aware that we ever received a response from the UI team on this thread. The PR was rolled back after it was approved. The contribution is something that we (Dell) provided based on internal work we are doing to host EdgeX in Kubernetes, so we require this feature.

 

Please advise.

 

Trevor Conn

Director of Software Engineering (DMTS)

Core Working Group Chair of EdgeX Foundry

Dell Technologies | IoT DellTech

Trevor_Conn@...

Round Rock, TX USA

 

 

From: Conn, Trevor
Sent: Wednesday, November 27, 2019 10:01 AM
To: 'Jason Bonafide'; Zhang, Huaqiao (c); Chen, Tiejun (VMware)
Cc: Bonafide, Jason
Subject: RE: EdgeX UI PR #138

 

+ Tiejun

 

From: Jason Bonafide <jbonafide623@...>
Sent: Wednesday, November 27, 2019 9:46 AM
To: Zhang, Huaqiao (c)
Cc: Bonafide, Jason; Conn, Trevor
Subject: Re: EdgeX UI PR #138

 

[EXTERNAL EMAIL]

CC-ing Trevor

 

On Wed, Nov 27, 2019 at 10:34 AM Jason Bonafide <jbonafide623@...> wrote:

Hello,

 

As discussed I wanted to follow up with an email based on some of the PR comments :)

 

As you mentioned in the PR comment. I recognize that the UI project was created without an API Gateway in the EdgeX ecosystem. My thoughts for the API Gateway support is that as EdgeX expands is used in more Enterprise Solutions, the need for supporting common MicroService Service Discovery Patterns (i.e. API Gateway) might become more in demand.

 

The use case I had for this is deploying EdgeX in Kubernetes. The main issue here would be Ingress routing. Due to the fact that, edgex-ui-go only supports configuring a host and port essentially means that the application would need to be directly available at said host and port. In several Enterprise solutions, routing techniques could include Load Balancers and Cluster Ingress Routing (Kubernetes). With that, Ingress/Egress Security concerns, we've opted to go with an API Gateway pattern as our service discovery pattern along with many other reasons.

 

The above kind of grazes over the requirement we have and why the suggestion of the issue itself.

 

With respect to the PR, by using an empty default Uri, it would preserve the original proxy functionality. I tested the backwards compatibility by deploying edgex using docker with positive results. My changeset would certainly add flexibility. I would agree, that my PR is not elegant, if that were to deemed as an "OK" approach, I would lean on your thoughts as to naming conventions because "CoreDataPath" and "CoreDataUri" could be incredibly confusing and seen as superfluous.

 

Please advise if this ultimately something of interest and if so, how would you recommend that we can incorporate this feature?

 

Regards,

 

Jason Bonafide


 

--

Best Regards,

Cloud Tsai


 

--

Best Regards,

Cloud Tsai

Join EdgeX-TSC-UI@lists.edgexfoundry.org to automatically receive all group messages.