feat(adr): Microservice authentication using E2EE #935
Conversation
| OpenZiti focuses on being a transport-level solution, | ||
| controlling access to remove services. | ||
| It does not provide application-level security. | ||
| The use of an OpenZiti tunneler causes remote connections |
There was a problem hiding this comment.
The use of an OpenZiti tunneler causes remote connections
appear to come from the tunneler instead of the true client.
missing a 'to' in there: "causes remote connections to appear to come from"
I'd also reword this maybe? For me, it's more about the inability of the tunneler to verify the original source of traffic (aka the true client). A tunneler-enabled solution to an http-based service would permit curl traffic, as well as browser traffic, etc. There's no way to know what the originating client was (unlike the fully application-embedded approach)
There was a problem hiding this comment.
Updates made. Please re-read these two paragraphs.
| an NGINX API gateway as part of the solution. | ||
| Since NGINX intercepts all requests to the backend, | ||
| and does not itself integrate directly with OpenZiti, | ||
| NGINX would need to use an OpenZiti tunneler to forward |
There was a problem hiding this comment.
I'd think they could also choose to use this nginx module https://github.com/openziti/ngx_http_ziti_module
There was a problem hiding this comment.
Updates made. Please re-read these two paragraphs.
The AS-IS is the EdgeX 2.x implementation and is a direct copy of https://docs.edgexfoundry.org/3.0/design/adr/security/0028-authentication/ AS-IS statement as this ADR was started in January. |
| However, to be fully functional, | ||
| and adopter must also run an OpenZiti controller, | ||
| one or more OpenZiti router components, | ||
| and zero or more OpenZiti tunnelers to support legacy applications. |
There was a problem hiding this comment.
Please give example of the legacy applications that would need to be supported.
There was a problem hiding this comment.
Added "Examples of a legacy applications include curl clients and Postman running in a users' browsers."
| and thus Vault must be available as a prerequisite | ||
| to the zero-trust network being available. | ||
| In EdgeX 3.0, | ||
| Vault is exposed behind a TLS-enabled NGINX API gateway (not shown), |
There was a problem hiding this comment.
From statement above, theAPI gateway is no longer needed. How does this impact this statement?
There was a problem hiding this comment.
Good point. I was trying to say that Vault still needs to be TLS-enabled regardless. An API gateway is not the only option. I have rewritten as such:
As Vault security is paramount, secure network communication with Vault must be possible, even before the zero-trust network is brought up. A non-exhaustive list of options, at the option of the adopter, includes:
- Vault is itself TLS-enabled
- Vault resides behind TLS-enabled API gateway
- Vault resides behind some kind of secure tunnel (e.g
stunnel) - Vault is accessible via an encrypted VPN
IMO, |
Signed-off-by: Bryon Nevis <bryon.nevis@intel.com>
Signed-off-by: edgex-jenkins <collab-it+edgex@linuxfoundation.org>
Signed-off-by: Bryon Nevis bryon.nevis@intel.com
PR Checklist
Please check if your PR fulfills the following requirements:
cc: @dovholuknf