Transparent proxy to corporate proxy in k8s

Attempting to deploy an external app into a corporate k8s cluster. All egress traffic leaving this external app has to go through the corporate proxy before getting to the internet. The issue is that the application does not have built in env variable support for the proxy. So setting http_proxy etc is not picked up and is not used by the application and we cannot modify the code to respect the env variables.

Our thought was to implement a transparent proxy that would intercept all outgoing traffic from the external application pod, re-route to the corporate proxy and then finally to the external internet address. Is there any software that would be able to be configured in the k8s as a transparent proxy while also having the ability to forward the request to the corporate proxy?

We attempted to use nginx but the main issue is that it doesn't seem to be able to be configured to use the corporate proxy. We had successfully configured nginx to use proxy_pass and re-route the request to the correct external URL but it was not using the proxy and subsequently received timeouts.

Any suggestions are appreciated.

So database lives in "West US 2" but Azure Function pulling data from the database is located in "North Central US" and because these resources are in different datacenters it is "unusual" because why wouldn't you keep everything in the same region?

You can confirm the IP reported in the alert matches the outbound IP range of the Azure Function going to that resource, selecting JSON View and searching for the suspicious IP. If you're having the same issue it'll be found in the "outboundIpAddresses" field.

Your problem here will be 2 fold

First, nginx is normally a reverse proxy, you want some thing like a set of firewall rules that will remap the destination address of all outbound traffic on port 80 or 443 to the proxy. You can use squid as an proper/forward http proxy.

You may be able to do all this with a sidecar container, but you will still have problems with my second point.

The second problem will be with HTTPS (traffic on port 443) that you can't just transparently proxy it normally, you would need a HTTP CONNECT action to open the port to the remote server so it can tunnel the HTTPS traffic otherwise the proxy will need to man in the middle the HTTPS and the application in the container will fail unless it's been configured to trust what ever certificate the proxy provides.