In this case “private network” would be your private resources inside AWS. Let me see if a couple of ASCII diagrams make things clearer. (They might not 
)
This is how Boundary proxying usually works (I’m leaving out the control plane here since it’s not part of the actual proxying): the worker sits on the network perimeter. The client connects directly to the worker and the worker forwards that connection to the target endpoint, then forwards the response back, and the client doesn’t have any idea any proxying is happening at all.
|
[client] <--> [worker] <--> [target: webapp]
|
However, you run into some issues with that when you have to preserve hostname info, because now everything is connecting through 127.0.0.1 by default and that tends to throw off things like TLS negotiation and host-based routing. So one model you can use to overcome that is to explicitly add an HTTP proxy in the private area, make that the Boundary connect target, and configure proxying on the client, so the hostname becomes meaningful again:
|
[client: proxy 127.0.0.1:some-port] <--> [worker] <--> [target: proxy:some-port] <--> [webapp]
|
Now in that second diagram, I think a Kubernetes Ingress gateway should work fine as that proxy, at least for things the Ingress is configured to route to, which you already saw some of when you were able to connect to various things through it when you connected to that target with Boundary and used it as a proxy.
When you’ve got things set up that way, I think you should be able to connect to http://myapp.com/jenkins and http://myapp.com/argocd as long as myapp.com points at your Ingress gateway and it has path-based routes for those services. If that works, then https:// to both of those should work too, as long as the cert is signed by a trusted CA and the Ingress gateway is configured properly.
I’m not sure what’s going on with proxying to external hosts though. As far as I know, anything not explicitly configured as an Ingress should be routed to the default 404-responder backend, which I think is what you’re seeing with the Boundary LB address when you try to connect there (a Boundary admin GUI 404 looks different than that, you wouldn’t get an nginx error). I don’t know why that’s not happening with google.com and other external public hosts.
We’re getting into territory where I’m half-speculating on what should work based on pieces I’ve done, though, so I’m going to see if I can’t put something more explicit together tonight or tomorrow, because this is a use case that comes up in general a lot but this is an interesting specific variation of that pattern that I haven’t really worked out yet.
So just to make sure I have your parameters right, you want:
- to be able to access
myapp.com/[various application paths] behind a Kubernetes Ingress, over both http: and https:, with it working as it normally would
- to be able to access other resources in that private network like the Boundary controller LB as well
- ideally, for that to not provide access to things outside the private network.
Do you have any special configuration set on that Ingress resource or is it just path-based routing to your backends? Is myapp.com explicitly set as a host on those Ingress resources or are they just using the ‘*’ host so they route that path to those services no matter what hostname you use?
