-
-
-
-
External proxy
-
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
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. SecurSpaces supports this natively through a single Helm values block: platform.externalProxy.
When configured, all outbound traffic from both Citrix SecurSpaces™ platform services and developer workspaces routes through the specified proxy. SecurSpaces 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.
Note:
This page is about routing SecurSpaces traffic through your organization’s outbound proxy. It is not about the SecurSpaces proxy service, which is an internal platform component that every workspace connection passes through and which needs no configuration. See How the SecurSpaces proxy service works.
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 SecurSpaces 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 SecurSpaces 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
SecurSpaces 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.
Share
Share
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.