Adding an HTTP Proxy to Self-Managed Deployment

This article is based on CUSTX-2034 that was created to add a proxy for FRB to communicate with their Okta IdM.

To have Immuta send requests through a HTTP proxy you have to set the HTTP_PROXY / HTTPS_PROXY environment variables at the Kuberentes pod level. This would be done by setting the secure.extraEnvVars setting in the helm chart to set environment variables for HTTP_PROXY, HTTPS_PROXY, and NO_PROXY. Some hostnames need to be set in the NO_PROXY environment variable for the system to work properly (for example, requests from our web service to generate data source fingerprints or SDD to bypass the proxy). A general reference on how to do this can be found here: https://www.arhea.net/posts/2020-06-16-kubernetes-http-proxies/

When customers introduce a HTTP Proxy for out-going connections, they’re going to have to spend some time configuring what connections go through the proxy and what connections do not go through the proxy. The new Helm Chart this easier because it uses FQDN’s (e.g., immuta-db.<k8s namespace>.svc.cluster.local) , which allows you to set NO_PROXY=svc.cluster.local,<...> which will be a catch-all for all k8s service-to-service communication.

An example of that would be:

NO_PROXY=svc.cluster.local,amazonaws.com,snowflakecomputing.com,mycompany.com

Those values would proxy all requests, except:

• svc.cluser.local - the domain used for service to service connections in Kubernetes (New Helm Chart always uses <service>.<namespace>.svc.cluster.local

• amazonaws.com - Most RDS hostnames are like <name>.<random chars>.us-east-1.rds.amazonaws.com

• snowflakecomputing.com - Snowflake API servers

• mycompany.com - An example of an internal server address