Custom TLS configuration for broker-to-backend connections

[jasonmadigan]

Is your feature request related to a problem? Please describe.

The MCP broker connects to upstream MCP servers using Go's default HTTP transport, which only trusts publicly-trusted CAs. This works for external services like GitHub's MCP server and in-cluster MCP servers with valid public certificates (#450 verified this, including full stack on OpenShift 4.20 with Let's Encrypt wildcard certs), but in-cluster MCP servers can often use private CAs (e.g. OpenShift service-serving CA, cert-manager, self-signed) which the broker rejects with a certificate verification error. There's no way to provide a custom CA bundle, override the TLS server name, or skip verification for development.

Describe the solution you'd like

I am not firm on an API, but something that exposes options like below that configures how the broker connects to HTTPS backends would be welcome:

spec:
  tls:
    caCertSecretRef:
      name: my-ca-bundle    # Secret containing CA PEM
    insecureSkipVerify: false # maybe? not sure we need this if we can inject bundles tbh

This only affects the broker path (init, tools/list). The tool call path flows through Envoy.

Open questions

• insecureSkipVerify -- is it needed? If providing a CA cert in a Secret is sufficient for development, skip-verify feels redundant?
• serverName override -- defer? Could be useful for SNI routing or IP-only endpoints, but niche and bypasses hostname verification. Bit of a shotgun otherwise.
• Policy separation. MCPServerRegistration already combines backend declaration + credential reference. Adding TLS override means one RBAC grant covers all three. Worth considering whether TLS config should live on a separate policy resource imho

Describe alternatives you've considered

• Inlining CA cert PEM in the MCPServerRegistration spec: simpler but doesn't support rotation without re-applying the CR, and bloats the resource
• Mounting CA bundles into the broker pod via volume mounts: works but requires Helm chart changes per-cluster and doesn't allow per-backend CA config?

Additional context

• Testing and defining support HTTPS for MCP Server backends #450 confirmed that HTTPS works today for publicly-trusted CAs (verified with GitHub MCP server on Kind and full stack on OpenShift 4.20 with Let's Encrypt)

[jasonmadigan]

cc @david-martin