Add HTTP proxy and corporate-CA support for SDK and bundled CLI - #2178
Open
misha-db wants to merge 14 commits into
Open
Add HTTP proxy and corporate-CA support for SDK and bundled CLI#2178misha-db wants to merge 14 commits into
misha-db wants to merge 14 commits into
Conversation
workspace TLS cert chains to an OS-trusted internal CA. Two causes:
- proxyAgent hardcoded loadSystemCertificatesFromNode: true, so
@vscode/proxy-agent called tls.getCACertificates (Node >= 22.15 only).
On older Node (shipped by many supported VS Code builds) it threw, the
OS store was lost, and the agent fell back to Node's bundled roots —
which don't include the corp CA.
- On the success path the agent set `ca` to only the OS store, which
*replaces* Node's bundled public roots (getCACertificates('system')
returns far fewer certs than tls.rootCertificates), a latent bug that
could break public-root TLS.
Fixes:
- Make loadSystemCertificatesFromNode version-aware so older runtimes use
proxy-agent's native readers (@vscode/windows-ca-certs on Windows,
security on macOS, PEM files on Linux).
- Always merge tls.rootCertificates + OS store + configured PEM; omit
`ca` entirely only when nothing extra is loaded.
- Add databricks.proxy.caCert setting as a cross-platform escape hatch.
- Ship @vscode/windows-ca-certs in the win32 VSIXs (win32-only optional
dep, copied into out/node_modules via package-vsix.sh gating).
A missing/failed native module degrades to bundled roots + caCert, never
a hard failure. TLS verification stays on by default throughout.
- buildCaBundle: dedupe with a Set (the OS store commonly re-lists the public roots already in tls.rootCertificates) and tighten the return type to string[] (it never produced Buffers). - getProxyEnvVars: document that http.proxy overrides the env var while no_proxy is unioned with it, not overridden. - Add a test asserting the CA bundle contains no duplicates.
Contributor
|
🤖 Integration tests ❌ failed for |
Preserve the Databricks SDK request timeout when injecting the extension's proxy-aware HTTP agent, including the SDK's default 5s timeout. Also merge VS Code http.noProxy with NO_PROXY/no_proxy for SDK proxy resolution so SDK calls and CLI subprocesses honor the same bypass list.
Contributor
|
🤖 Integration tests ❌ failed for |
Contributor
|
🤖 Integration tests running for |
Contributor
|
🤖 Integration tests ❌ failed for |
Contributor
|
🤖 Integration tests ❌ failed for |
Contributor
|
If integration tests don't run automatically, an authorized user can run them manually by following the instructions below: Trigger: Inputs:
Checks will be approved automatically on success. |
Contributor
|
🤖 Integration tests ❌ failed for |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changes
What
Makes the extension work behind corporate HTTP/HTTPS proxies and against
workspaces whose TLS certificate is signed by an internal CA — for both the
in-process Databricks JS SDK and the bundled Go CLI.
Why
Users on corp-managed machines (proxy-only networks, TLS-intercepting proxies,
internal CAs) currently hit two problems:
picked one up from OS env vars — never from the VS Code
http.proxysetting.global TLS patching), so an OS-trusted internal CA was ignored and SDK calls
failed with
SELF_SIGNED_CERT_IN_CHAIN/UNABLE_TO_GET_ISSUER_CERT_LOCALLY.The bundled Go CLI was unaffected (it reads the OS store natively).
What changed
Proxy resolution (SDK + CLI)
src/utils/network/proxyAgent.tsbuilds a proxy- and CA-aware agent via@vscode/proxy-agent, resolving the proxy the way VS Code core does:http.proxysetting first, thenhttp(s)_proxyenv vars, honoringhttp.noProxy/NO_PROXY.createWorkspaceClientis now the single placethe extension constructs a
WorkspaceClient; the auth checks (AuthProvider,AzureCliCheck,DatabricksCliCheck) route through it.getProxyEnvVars(forwarded to the CLI subprocess) now also reads the VS Codehttp.proxy/http.noProxysettings, not just OS env vars — the Go CLIhonors a proxy only through these env vars, so this keeps the CLI and SDK
resolving the same proxy from the same inputs.
Certificate trust (SDK)
cais built by merging Node's bundled roots(
tls.rootCertificates) + the OS trust store + an optional user PEM, deduped.Previously the OS store replaced the bundled roots, which could break
public-root TLS.
tls.getCACertificates;on older runtimes (shipped by many supported VS Code builds) it falls back to
@vscode/proxy-agent's native readers, which is why the win32 VSIXs now shipthe native
@vscode/windows-ca-certsmodule (win32-only optional dependency,copied into
out/at package time).databricks.proxy.caCertsetting — an absolute path to a PEM bundle — asa cross-platform escape hatch, merged onto the trust store.
Strict SSL
databricks.proxy.strictSSLsetting overrides the built-inhttp.proxyStrictSSL(both default to verification on). Activation and the SDKclient path now resolve strict-SSL through the same layered setting, so the
DATABRICKS_SDK_PROXY_STRICT_SSLenv var (read by the SDK fetch path) isconsistent and defaults to on when nothing is configured.
Graceful degradation
Every failure path is recoverable: an unreadable OS store or missing native
module falls back to Node's bundled roots, an unreadable
caCertpath is loggedand ignored, and none of these break the agent. TLS verification stays on by
default throughout.
Tests
caCert(success + fallback +unreadable path), the version-aware flag, and strict-SSL env wiring.
yarn workspace databricks run test:unit— all green (1078 passing).Not covered by CI: the old-Node Windows corp-CA path requires the native
module to actually be present, which depends on the win32 VSIX being built on a
Windows host. Verify the release pipeline before relying on it; the
databricks.proxy.caCertsetting is the fallback if it isn't shipped.