External Proxy Configuration
Many enterprise environments require all outbound HTTP/HTTPS traffic to flow through a corporate proxy — for egress filtering, TLS inspection, or compliance logging. SDS supports this natively through a single Helm values block: platform.externalProxy.
When configured, all outbound traffic from both SDS platform services and developer workspaces routes through the specified proxy. SDS handles proxy configuration automatically inside workspaces — it injects the standard HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment variables, and most CLI tools (curl, git, apt, pip, npm, language runtimes) honor them by default.
Configuration block
The configuration lives under platform.externalProxy in your Helm values file:
platform:
externalProxy:
httpsProxyUrl: ""
httpProxyUrl: ""
certificate: ""
noProxyList: ""
<!--NeedCopy-->
If you omit the externalProxy block entirely, traffic flows directly from the cluster without a proxy.
Fields
httpsProxyUrl
The proxy URL used for HTTPS traffic. Format: http://host:port or https://host:port (the protocol of the proxy itself, not the traffic being proxied).
If httpsProxyUrl is set but httpProxyUrl isn’t, HTTPS traffic uses this value, and HTTP traffic falls back to it as well.
httpProxyUrl
The proxy URL used for HTTP traffic. Same format as above.
If httpProxyUrl is set but httpsProxyUrl isn’t, HTTP traffic uses this value, and HTTPS traffic falls back to it.
In most corporate setups, a single proxy handles both protocols, so it’s common to configure just one of the two and rely on the fallback. Set both explicitly only if your environment uses different proxies for HTTP and HTTPS.
certificate
If your proxy performs TLS inspection (sometimes called TLS interception, man-in-the-middle proxying, or “break-and-inspect”), it presents its own certificate to clients instead of the origin server’s. To trust it, provide the proxy CA certificate here.
The certificate must be PEM-encoded, then base64-encoded, before being placed in the values file. Generate the value with:
base64 -w 0 < proxy-ca.pem
<!--NeedCopy-->
(or base64 -i proxy-ca.pem on macOS). Paste the resulting single-line string as the value.
If you need to trust multiple certificates (for example, a root CA plus an intermediate, or several proxies in different regions), concatenate all the PEM blocks into a single file before base64-encoding. Each certificate must keep its full -----BEGIN CERTIFICATE----- / -----END CERTIFICATE----- markers:
cat root-ca.pem intermediate-ca.pem proxy-ca.pem > combined.pem
base64 -w 0 < combined.pem
<!--NeedCopy-->
The order doesn’t matter for trust evaluation — all certificates in the bundle are added to the trust store.
When set, the certificate is added to the trust store of every SDS service container and every workspace container, so HTTPS calls through the proxy validate correctly without per-application configuration.
Leave empty if your proxy doesn’t perform TLS inspection or uses a publicly trusted certificate.
noProxyList
A comma-separated list of hosts, domains, and IP addresses that bypass the proxy. Use this for internal services that the proxy can’t reach or that don’t need inspection — your internal Git server, a private container registry, internal package mirrors, the Kubernetes API, and so on.
Format rules:
- Comma-separated, no spaces between entries
- A leading dot (
.example.com) matches the domain and all its subdomains - A bare hostname (
example.com) matches that host only - IP addresses (
192.168.1.10) and CIDR ranges (10.0.0.0/8) are supported - Ports can be appended with a colon (
example.com:8443)
In-cluster traffic (anything that resolves to a cluster.local address or a pod/service IP) is already excluded and doesn’t need to be listed here.
Worked example
A typical corporate deployment with a TLS-inspecting proxy at proxy.corp.example.com:8080, an internal Git server, and a private registry:
platform:
externalProxy:
httpsProxyUrl: "http://proxy.corp.example.com:8080"
httpProxyUrl: "http://proxy.corp.example.com:8080"
certificate: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURxRENDQXBDZ0F3SUJBZ0lVRkV4..."
noProxyList: ".corp.example.com,git.internal,registry.internal,10.0.0.0/8"
<!--NeedCopy-->
What this does:
- All outbound HTTP and HTTPS traffic from SDS services and workspaces routes through
proxy.corp.example.com:8080. - The proxy CA certificate is trusted everywhere, so TLS inspection works without certificate errors.
- Anything under
*.corp.example.com, plus the two internal hostnames and the10.0.0.0/8private range, bypasses the proxy and connects directly.
Applying changes
SDS reads platform.externalProxy at pod startup. After you update the values and run helm upgrade, services pick up the new configuration when their pods restart. Existing workspace pods continue to use the proxy settings they started with — restart the workspace to pick up changes.
Troubleshooting
Certificate errors (x509: certificate signed by unknown authority, SSL_ERROR_BAD_CERT_DOMAIN): The proxy performs TLS inspection, but certificate is unset or contains the wrong CA. Verify with openssl s_client -connect <any-https-host>:443 -proxy proxy.corp.example.com:8080 from inside a workspace and check which certificate is presented.
Internal hosts unreachable: A noProxyList entry is missing. Subdomain matching requires the leading dot.
Base64 decoding errors at deploy time: The certificate value must be a single line with no embedded newlines. Re-run base64 -w 0 to flatten it.