Route outbound traffic through a corporate proxy
During installation, tare install asks up to three questions about outbound HTTP proxying, and the answers decide how both control traffic and LLM traffic leave the cluster. Settle the topology before running the installer: answering n to the first question skips the rest, so a single keystroke sets the whole egress shape.
Persona: Platform operator installing the data plane, with the network team's answer on how outbound traffic must leave the cluster.
Estimated time: 10 minutes to read; the decision itself belongs to the network review before install day.
The two egress paths
The data plane sends traffic out of the cluster on two different paths, configured separately:
| Path | What travels on it | Environment it renders to |
|---|---|---|
| Management traffic | The controller and worker reaching the management plane, and the self-upgrade jobs fetching release manifests | HTTP_PROXY, HTTPS_PROXY, and NO_PROXY on the controller, controller-worker, and data-plane Envoy pods |
| LLM egress | Envoy forwarding AI requests to model providers on the data path | EGRESS_FORWARD_PROXY_ADDRESS on the ai-gateway-controller, plus a hostname-suffix skip list |
The split exists because Envoy's data path does not read the HTTP_PROXY environment variables: proxying LLM traffic takes an explicit forward proxy. EGRESS_FORWARD_PROXY_ADDRESS carries a bare host:port, derived automatically from the HTTP_PROXY URL unless overridden, and when the URL has no parseable host and port the installer prints a warning that the forward proxy will not be set, in which case LLM traffic goes direct.
The environment variable names are worth knowing because the wizard's answers become ordinary Helm values and pod environment, so what was actually configured is verifiable after the fact instead of remembered:
kubectl get deployments --all-namespaces -o yaml | grep -E 'EGRESS_FORWARD_PROXY_ADDRESS|HTTP_PROXY' -A1
An audit of rendered values works the same way: the wizard runs before the Helm values are generated, so tare install --print-helm-values reflects the same answers a real install would apply.
What the installer asks, and the flag behind each question
| Prompt | Flag | What it sets |
|---|---|---|
Configure outbound HTTP proxy for controller/worker/Envoy pods? [y/N] | (gate) | n skips every question below; nothing is proxied |
HTTP_PROXY URL (e.g. http://10.10.2.4:8888) | --http-proxy | HTTP_PROXY on the pods above, and the value the LLM forward proxy is derived from |
HTTPS_PROXY URL [default: HTTP_PROXY] | --https-proxy | HTTPS_PROXY; left blank in the wizard it takes the HTTP_PROXY value. The flag does not default: pass both explicitly |
NO_PROXY (comma-separated, e.g. .svc,.cluster.local,10.0.0.0/8) | --no-proxy | NO_PROXY: hostnames, domain suffixes, and CIDR ranges |
Also tunnel envoy's LLM egress through this proxy? [Y/n] | --forward-proxy-address | Y (the default) derives EGRESS_FORWARD_PROXY_ADDRESS from HTTP_PROXY; n disables it, so Envoy reaches LLM endpoints directly while management traffic stays on the proxy |
Hostname suffixes to skip the forward proxy (e.g. .openai.azure.com) | --forward-proxy-no-proxy | Per-host opt-outs from the LLM forward proxy; only effective while the forward proxy is active |
Passing any of --http-proxy, --https-proxy, or --no-proxy suppresses the whole wizard: flags are trusted as the non-interactive answer. The wizard also never runs when stdin is not a terminal (CI, pipes) or when stdin was already consumed by --image-pull-secret-stdin. A scripted install without explicit flags therefore configures no proxy, silently. For CI and GitOps, the flags are the contract.
The same flags exist on tare upgrade, so a topology set at install time survives upgrades scripted the same way.
Topology 1: everything through the proxy
The default shape behind a corporate forward proxy: management traffic and LLM traffic both tunnel through it.
Wizard answers, in order: y, the proxy URL, Enter (HTTPS same as HTTP), the NO_PROXY list, Y, Enter (no skip suffixes). Non-interactively:
tare install identity.json \
--http-proxy http://10.10.2.4:8888 \
--https-proxy http://10.10.2.4:8888 \
--no-proxy .svc,.cluster.local,10.0.0.0/8
NO_PROXY keeps in-cluster traffic off the proxy. Start from .svc,.cluster.local plus the cluster's pod and service CIDRs, and extend it with any other in-network endpoint the pods reach directly.
Topology 2: proxy for management traffic, direct LLM egress
The shape for LLM endpoints reachable privately, without leaving the network: Bedrock over an interface VPC endpoint, Azure OpenAI behind a Private Endpoint, or Vertex through GCP Private Service Connect. Management traffic still needs the corporate proxy; the LLM tunnel must stay off.
Wizard answers: y, the proxy URL, Enter, the NO_PROXY list, then n at the tunnel question. The installer confirms with forward-proxy egress disabled — envoy reaches the LLM directly. Non-interactively, the explicit empty value is the disable:
tare install identity.json \
--http-proxy http://10.10.2.4:8888 \
--https-proxy http://10.10.2.4:8888 \
--no-proxy .svc,.cluster.local,10.0.0.0/8 \
--forward-proxy-address ""
Mixed: proxy for most providers, direct for some
When most LLM traffic goes through the proxy and only some endpoints are private, keep the tunnel on and list the private endpoints as skip suffixes, in the wizard's last question or as a flag:
tare install identity.json \
--http-proxy http://10.10.2.4:8888 \
--https-proxy http://10.10.2.4:8888 \
--no-proxy .svc,.cluster.local,10.0.0.0/8 \
--forward-proxy-no-proxy .openai.azure.com
NO_PROXY follows the usual environment-variable convention: hostnames, domain suffixes, and CIDR ranges such as 10.0.0.0/8. The forward-proxy skip list takes hostname suffixes only, matched case-insensitively with a leading dot tolerated; a CIDR entry there matches nothing. The same network, excluded on both paths, is written two different ways.
Where to go next