fix(docker): honor DOCKER_TLS_VERIFY/DOCKER_CERT_PATH env vars (#607)

[CybotTM]

Summary

Fixes #607. TLS sibling of #606 (which fixes the dialer-divergence half of the same root cause).

When DOCKER_HOST=https://... is used together with DOCKER_TLS_VERIFY=1 and DOCKER_CERT_PATH=..., Ofelia silently discarded the TLS material — the resulting *http.Transport had a nil TLSClientConfig, so the daemon either rejected the handshake or got an unauthenticated connection where mTLS was intended. Latent since the SDK adapter landed in v0.12.0.

Root cause

NewClientWithConfig configures the SDK in two passes that don't compose:

1. client.FromEnv runs WithTLSClientConfigFromEnv(), which builds a *tls.Config from DOCKER_CERT_PATH / DOCKER_TLS_VERIFY and assigns it onto a fresh http.Client.Transport — i.e. it replaces c.client.
2. client.WithHTTPClient(httpClient) then overwrites c.client again with our custom transport, which never sees the TLS config from step 1.

So whichever step runs last wins, and step 2 always wins. The exact same shape as #606's WithHostFromEnv vs custom dialer divergence.

Fix

In createHTTPClient, when the resolved host scheme is https://, build a *tls.Config via go-connections/tlsconfig.Client (already a dependency) and assign it to transport.TLSClientConfig. Two new fields on ClientConfig allow explicit override: TLSCertPath string and TLSVerify *bool. Precedence mirrors resolveDockerHost from #606: config field > env var > unset.

DOCKER_TLS_VERIFY semantics match the SDK exactly: any non-empty value (including "0") means verify; only an unset/empty value disables it. When neither config nor env supply a cert path, no TLS is applied (matching the SDK's "leave TLS untouched" behavior).

A small helper, resolveHostForTransport, also consults DOCKER_HOST so the HTTPS branch is selected in the same configurations the SDK targets — avoiding a related divergence where empty config.Host would fall back to the unix default and skip the TLS branch entirely.

Test plan

• New tests in core/adapters/docker/client_mutation_test.go:
  • TestCreateHTTPClient_HonorsTLSEnv — DOCKER_HOST=https://127.0.0.1:0 + cert path, asserts TLSClientConfig.{RootCAs, Certificates} populated and InsecureSkipVerify=false
  • TestCreateHTTPClient_ExplicitTLSOverridesEnv — cfg.TLSCertPath + cfg.TLSVerify win over env-supplied values
  • TestCreateHTTPClient_NoTLSForUnixSocket — unix socket path → no TLS even with env set
  • TestCreateHTTPClient_NoTLSWhenCertPathEmpty — empty cert path → SDK-equivalent "no TLS modification"
• Verified the bug exists on the unmodified code: a stripped-down version of the env test fails with BUG #607 confirmed: transport.TLSClientConfig is nil; TLS env not honored before the fix
• go test -race ./core/adapters/docker/ ./core/ passes
• go test -race ./... passes (full module)
• golangci-lint run --timeout=3m ./... clean
• All TLS material in tests is generated under t.TempDir(); loopback-only 127.0.0.1:0 (no parallel-test contamination, per fix(docker): honor DOCKER_HOST env var when selecting transport dialer #606 review)

Scope

Self-contained — no go.mod/go.sum change (go-connections/tlsconfig was already a transitive dep), no impact on the unix-socket / TCP code paths.

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[github-actions]

Automated approval for maintainer PR

All automated quality gates passed. See SECURITY_CONTROLS.md for compensating controls.

[github-actions]

✅ Mutation Testing Results

Mutation Score: 100.00% (threshold: 60%)

✨ Good job! Mutation score meets the threshold.

What is mutation testing?

Mutation testing measures test quality by introducing small changes (mutations) to the code and checking if tests detect them. A higher score means better test effectiveness.

• Killed mutants: Tests caught the mutation (good!)
• Survived mutants: Tests missed the mutation (needs improvement)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.34%. Comparing base (73bbc6a) to head (db9f62f).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #613      +/-   ##
==========================================
+ Coverage   87.29%   87.34%   +0.04%     
==========================================
  Files          88       88              
  Lines       10677    10719      +42     
==========================================
+ Hits         9320     9362      +42     
- Misses       1115     1116       +1     
+ Partials      242      241       -1     

Flag	Coverage Δ
integration	87.32% <100.00%> (+0.03%)	⬆️
unittests	83.93% <100.00%> (+0.08%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ 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.

[gemini-code-assist]

Code Review

This pull request updates the Docker SDK adapter to properly honor DOCKER_TLS_VERIFY and DOCKER_CERT_PATH for HTTPS hosts, addressing an issue where custom HTTP clients would silently discard TLS material. It introduces TLSCertPath and TLSVerify to ClientConfig and implements logic to resolve host and TLS settings with precedence for configuration over environment variables. Feedback indicates a potential security risk where errors in TLS configuration resolution are ignored; it is recommended to refactor the client creation to fail-fast upon encountering such errors.

[Copilot]

Pull request overview

This pull request fixes a Docker SDK adapter bug where DOCKER_TLS_VERIFY / DOCKER_CERT_PATH TLS material was being lost when Ofelia installs its custom http.Client via client.WithHTTPClient, ensuring TLS configuration is applied on the custom transport as well.

Changes:

• Add ClientConfig.TLSCertPath and ClientConfig.TLSVerify to allow explicit TLS configuration with config > env precedence.
• Extend createHTTPClient to resolve the effective host (including DOCKER_HOST) and apply TLS config for HTTPS transports.
• Add regression tests generating temporary TLS fixtures and update CHANGELOG.md with the fix.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
core/adapters/docker/client.go	Adds host resolution for transport selection and TLS config resolution/application for HTTPS hosts.
core/adapters/docker/client_mutation_test.go	Adds regression tests ensuring TLS env/config precedence and TLS/no-TLS behavior across host types.
CHANGELOG.md	Documents the TLS env var fix and new config overrides under Unreleased.

Comments suppressed due to low confidence (2)

core/adapters/docker/client.go:199

• TLS is only applied when the resolved host string starts with "https://". However repo docs show the common TLS setup as DOCKER_HOST=tcp://... with DOCKER_TLS_VERIFY/DOCKER_CERT_PATH (e.g. docs/SECURITY.md). With tcp:// the code falls into the default branch and never calls resolveTLSConfig, so client cert/CA material will still be discarded in that configuration. Consider applying TLS whenever a cert path is configured (and host is not unix://), or explicitly handling the tcp:// scheme used by Docker for TLS endpoints.

This issue also appears on line 189 of the same file.

	// Configure dialer based on host type
	switch {
	case strings.HasPrefix(host, "unix://"):
		socketPath := strings.TrimPrefix(host, "unix://")
		transport.DialContext = func(ctx context.Context, network, addr string) (net.Conn, error) {
			dialer := &net.Dialer{Timeout: config.DialTimeout}
			return dialer.DialContext(ctx, "unix", socketPath)
		}
		// HTTP/2 not supported on Unix sockets
		transport.ForceAttemptHTTP2 = false
	case strings.HasPrefix(host, "https://"):
		// HTTPS connections can use HTTP/2 via ALPN
		transport.ForceAttemptHTTP2 = true
		// Apply TLS from explicit config / env. The SDK's client.FromEnv
		// also tries to apply this, but client.WithHTTPClient below
		// overwrites the SDK's http.Client wholesale and would discard
		// that TLS material — see issue #607.
		if tlsCfg, err := resolveTLSConfig(config); err == nil && tlsCfg != nil {
			transport.TLSClientConfig = tlsCfg
		}
	default:
		// TCP without TLS - HTTP/2 not supported (no h2c in Docker)
		transport.ForceAttemptHTTP2 = false
	}

core/adapters/docker/client.go:195

• Errors from resolveTLSConfig are silently ignored (err == nil guard). If TLS files are missing/invalid, Ofelia will proceed with an HTTPS transport but without the intended client cert/CA config, which can lead to confusing failures or an unintended unauthenticated TLS connection. It would be safer to propagate this error (e.g. have createHTTPClient/NewClientWithConfig return an error) so misconfiguration is surfaced early.

		// Apply TLS from explicit config / env. The SDK's client.FromEnv
		// also tries to apply this, but client.WithHTTPClient below
		// overwrites the SDK's http.Client wholesale and would discard
		// that TLS material — see issue #607.
		if tlsCfg, err := resolveTLSConfig(config); err == nil && tlsCfg != nil {
			transport.TLSClientConfig = tlsCfg
		}

[github-actions]

Automated approval for maintainer PR

All automated quality gates passed. See SECURITY_CONTROLS.md for compensating controls.

[github-actions]

Automated approval for maintainer PR

All automated quality gates passed. See SECURITY_CONTROLS.md for compensating controls.

[github-actions]

Automated approval for maintainer PR

All automated quality gates passed. See SECURITY_CONTROLS.md for compensating controls.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

Automated approval for maintainer PR

All automated quality gates passed. See SECURITY_CONTROLS.md for compensating controls.