feat(http): implement tls serving certs for server

[mjudeikis]

Add tls service certs, allowing to provide TLS certificates to the server itself.

This allows usages:

• serviceType: Loadbalancer + external certs
• certmagic as side container

In general simplified configuration when neither ingress or gateway is available

[mjudeikis]

Still, a few other things are needed. Not straight forward as I expected :D

[manusa]

Thanks for taking care of this!

The TLS implementation looks good overall. A few notes:

Dockerfile change: As discussed in the comments, this should be handled in #752. Once #752 is merged with the ENTRYPOINT/CMD split pattern:

ENTRYPOINT ["/app/kubernetes-mcp-server"]
CMD ["--port", "8080"]

The Helm chart will work correctly because:

1. The deployment template uses args (not command), which replaces CMD in Kubernetes
2. With your extraArgs addition, the final args become: ["--config", "/path/to/config.toml", "--tls-cert=...", "--tls-key=..."]
3. The port is then specified via the config file (config.port), not the Dockerfile

So the recommendation is to drop the Dockerfile change from this PR and let #752 handle it with the proper backward-compatible approach.

The extraArgs pattern: This is a good addition that provides flexibility for TLS and other future configuration options. It appends to the base args rather than replacing them entirely.

[mjudeikis]

@manusa ready. tests look like flakes, and I don't have access to rerun

[manusa]

Thx for this improvement!
I think it's looking good, I added a few minor comments.

[mjudeikis]

@manusa hope this is what you expected in your comments :)

[mjudeikis]

@mjudeikis-bot follow this pr and let me know if my attention here is needed.

[mjudeikis-bot]

On it — monitoring this PR.

Current status: @manusa has CHANGES_REQUESTED (Feb 18); you addressed all inline comments today. The PR is mergeable (no conflicts), and @Cali0707 is a requested reviewer.

Action needed: @manusa asked at 14:24 today: "shall I merge that one first?" (referring to #798, the CI job for README dirtiness checks) — that question appears unanswered. You may want to respond before @manusa does a final re-review.

[manusa]

When TLS is enabled via extraArgs, the default livenessProbe and readinessProbe in values.yaml use httpGet with port: http. These HTTP probes will fail against an HTTPS endpoint since the server won't respond to plain HTTP.

Since TLS is configured through opaque extraArgs, the chart has no way to auto-set scheme: HTTPS on the probes. Users would need to manually override probes, volumes, and volume mounts — which is error-prone.

Minimal fix: Document the required probe override in the comments here (e.g., show that users must also set livenessProbe.httpGet.scheme: HTTPS).

Better approach: Add a first-class tls section to the chart values instead of relying on extraArgs for TLS:

tls:
  enabled: false
  secretName: ""
  mountPath: /etc/tls

When tls.enabled is true, the chart template would automatically:

• Inject --tls-cert and --tls-key args
• Mount the TLS secret as a volume
• Set scheme: HTTPS on health probes

This is the standard pattern used by most Helm charts (cert-manager webhook, ingress-nginx, etc.) and provides a much better UX — users just set tls.enabled: true and tls.secretName: my-cert.

The extraArgs value is still useful as a generic escape hatch for other flags.

[manusa]

These new TOML options should also be documented in docs/configuration.md. Other similar fields like certificate_authority and server_url are already documented in the configuration reference table there.

[manusa]

Nit: TLS is only meaningful in HTTP mode (when port is set). Consider also validating that port is configured when TLS cert/key are provided:

if tlsCert != "" && m.StaticConfig.Port == "" {
    return fmt.Errorf("--tls-cert and --tls-key require --port to be set (TLS is only supported in HTTP mode)")
}

This would give users a clear early error instead of silently ignoring the TLS config in STDIO mode.

[manusa]

Hi, thx for taking care of the previous comments.
I reported a few more minor things 😅 otherwise, I think we should be ready to go 🚀

[mjudeikis-bot]

👋 @mjudeikis — new review comments from @manusa just landed (2026-02-26). Flagging as you asked:

3 items need attention:

1. Helm probes fail with TLS — the default livenessProbe/readinessProbe in values.yaml use httpGet, which will fail against an HTTPS endpoint when TLS is enabled via extraArgs. The chart cannot auto-detect this from opaque args, so either the probes need to be switched to tcpSocket/exec for TLS, or the chart needs a dedicated tls.enabled flag.

2. Missing docs in configuration.md — the new tls-cert and tls-key TOML options are not yet documented in docs/configuration.md. Other similar fields (e.g. certificate_authority, server_url) are already in the reference table there.

3. Nit: port validation — manusa suggests validating that --port is set when --tls-cert/--tls-key are provided, since TLS only makes sense in HTTP mode.

All three are blocking or near-blocking for merge. Helm probe fix is the most critical.