Block private and loopback dials in webhook HTTP client

[JAORMX]

Summary

Follow-up to the round-2 review of #4564 (item #5). A tenant with rights to create MCPWebhookConfig could previously point url at any HTTPS endpoint, including 169.254.169.254 (cloud metadata), 127.0.0.1, RFC1918 ranges, and IPv6 loopback / link-local / ULA addresses. The webhook HTTP transport built a bare http.Transport with no DialContext; the wrapping networking.ValidatingTransport only checks the URL scheme — it does not validate the resolved peer address — so cross-tenant access to cloud metadata or in-cluster services was unblocked.

This PR wires networking.ProtectedDialerControl into the inner transport's DialContext so private, loopback, and link-local destinations are rejected at dial time, regardless of whether ValidatingTransport's HTTPS check is bypassed via InsecureAllowHTTP. The hook is held in an atomic.Pointer so test overrides remain race-free if a future test introduces t.Parallel().

protectedDialerControl is exported as ProtectedDialerControl in pkg/networking so the webhook package can install it without duplicating the body. Cross-package test injection (SetDialerControlForTesting, SetDialerControlForTestMain, AllowAnyDialerControl) is added so the existing httptest-based suite in pkg/webhook and its subpackages keeps working; subpackage TestMain functions install the permissive override at suite startup.

Type of change

• Bug fix

Test plan

• Unit tests (task test — pkg/webhook/... and pkg/networking/... pass with -race)
• Linting (scoped golangci-lint reports 0 issues)
• New TestClientSSRFGuardBlocksPrivateAddress covers IPv4 loopback, RFC1918, and 169.254.169.254, plus IPv6 loopback (::1), link-local (fe80::1), and ULA (fc00::1).
• New TestBuildTransportInstallsDialerGuard asserts DialContext is wired on the inner transport.

Special notes for reviewers

• The three exported test helpers in pkg/webhook/dialer_testing.go add public surface area in service of cross-package test injection. A reviewer raised the option of moving them to a pkg/webhook/internal/dialer subpackage; that's a viable follow-up but feels like scope creep here. Each helper has a Production code MUST NOT call this function deterrent in its godoc and the testing.TB argument signals test-scoped intent.
• Item Figure out ergonomics for exposing directories #6 (InsecureSkipVerify conflates cert-skip with plaintext-HTTP) and item Implement secret injection #5's broader IPv6 coverage in pkg/networking itself are tracked separately.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 68.84%. Comparing base (6f63ac0) to head (cb9b4ad).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5190      +/-   ##
==========================================
+ Coverage   68.77%   68.84%   +0.07%     
==========================================
  Files         629      630       +1     
  Lines       63914    63931      +17     
==========================================
+ Hits        43955    44012      +57     
+ Misses      16703    16664      -39     
+ Partials     3256     3255       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jhrozek]

One non-blocking design note from reviewing the SSRF fix. The change itself is correct and closes a real gap — this is just a thought on where the plumbing could live longer-term.

[jhrozek]

Non-blocking / follow-up thought, not for this PR.

This hand-builds a transport with its own dialer guard, but pkg/networking.HttpClientBuilder already does almost exactly this: it installs ProtectedDialerControl and gives tests a clean opt-out via WithPrivateIPs(true) — no package-level global, no atomic.Pointer, and no exported test helpers. The bespoke dialerControl global (plus dialer_testing.go, which is the only *_testing.go file in the repo) is really what forces us to export the guard-disabling helpers.

As far as I can tell, only two gaps stop webhook from just using the builder today:

• mTLS client certs (ClientCertPath/ClientKeyPath)
• a tls.Config.InsecureSkipVerify knob distinct from the HTTP-allow knob

So a possible follow-up (bigger than this PR): add WithClientCert(certPath, keyPath) and WithInsecureSkipVerify(bool) to HttpClientBuilder, then have webhook call the builder and delete the global + dialer_testing.go entirely. Happy to file an issue for it rather than expand scope here.

[JAORMX]

Agreed — the builder is clearly the better long-term home for this, and folding webhook into it would let us delete the global dialerControl pointer and dialer_testing.go entirely. I'll file a follow-up issue for adding WithClientCert/WithInsecureSkipVerify to HttpClientBuilder and migrating webhook onto it. This is non-blocking for the SSRF fix here, so no changes needed in this PR.

[JAORMX]

Update: went ahead and did this in the PR rather than filing a follow-up. Added WithClientCert/WithInsecureSkipVerify to HttpClientBuilder, migrated buildTransport to build the client through it, and replaced the dialerControl global/atomic.Pointer/dialer_testing.go machinery with a plain atomic.Bool test-only flag. All existing tests (including the SSRF guard integration test) pass unchanged.