Repository navigation
TLS configuration for VirtualMCPServer Redis session storage #6730
Description
Activity
@kraashen Thanks for reporting this. I confirmed that
sessionStoragecurrently cannot request TLS, although the underlying Redis client supports it. I’ll take ownership of the implementation.I propose the following acceptance criteria:
- An optional
sessionStorage.tlssetting: omission preserves current plaintext behavior;tls: {}enables certificate-verified TLS using system roots. - The setting works across
VirtualMCPServer,MCPServer, andMCPRemoteProxy, which share the session-storage API. - Both session storage and its separate Redis-backed rate-limiting connection use the requested TLS settings. A failed TLS connection must not fall back to plaintext.
- The vMCP YAML configuration used by
thv vmcpsupports the same behavior. This does not appear to require a new CLI flag. - Tests cover a TLS-only Redis endpoint, the existing plaintext behavior, and invalid certificate configuration.
I also plan to support a CA Secret for Redis deployments using a private CA, following the existing embedded auth-server pattern. TLS for the Helm operator-wide
defaultRedisfallback is a separate configuration path; I’ll track it in a linked follow-up rather than include it here.- An optional
@kraashen Thanks for reporting this. I confirmed that
sessionStoragecurrently cannot request TLS, although the underlying Redis client supports it. I’ll take ownership of the implementation.I propose the following acceptance criteria:
- An optional
sessionStorage.tlssetting: omission preserves current plaintext behavior;tls: {}enables certificate-verified TLS using system roots. - The setting works across
VirtualMCPServer,MCPServer, andMCPRemoteProxy, which share the session-storage API. - Both session storage and its separate Redis-backed rate-limiting connection use the requested TLS settings. A failed TLS connection must not fall back to plaintext.
- The vMCP YAML configuration used by
thv vmcpsupports the same behavior. This does not appear to require a new CLI flag. - Tests cover a TLS-only Redis endpoint, the existing plaintext behavior, and invalid certificate configuration.
I also plan to support a CA Secret for Redis deployments using a private CA, following the existing embedded auth-server pattern. TLS for the Helm operator-wide
defaultRedisfallback is a separate configuration path; I’ll track it in a linked follow-up rather than include it here.@JAORMX @ChrisJBurns PTAL
I have already raised a PR accordingly.- An optional
Context
VirtualMCPServerRedis session storage always seems to connect in plaintext based on configs and current code layout.redisconn in toolhive-core already supports TLS, but nothing on the Virtual MCP path sets
redisconn.Config.TLSasspec.sessionStoragehas no TLS settings (as in here), and therefore it'll behave asnilin thetoolhive-core's Redis config side.A non-nil TLSConfig would enable TLS. A nil one stays plaintext. An empty
redisconn.TLSConfig{}would be enough for TLS 1.2+ with system root CAs and certificate verification. Session storage has no field that can produce that value.Expected behavior
Would it be possible to have
sessionStorageto be able to request TLS? EmptyTLSConfigwould use system CA bundles, and that value could be passed through toredisconn.Config.TLS.go-redisseemigly produces and enabled TLS this way.Existing use of TLS:
The same config resource is also used by
MCPServerandMCPRemoteProxy, so a CRD field would show up on those resources as well?