bug: gateway logs InvalidContentType TLS errors every 5s from kubelet probes

[sjenning]

Agent Diagnostic

Investigated the gateway pod logs and Helm statefulset template. The liveness and readiness probes use tcpSocket on the gateway's gRPC port. When TLS is enabled, kubelet opens a raw TCP connection and sends plaintext bytes, which the rustls TLS acceptor rejects with InvalidContentType. This produces ERROR-level log lines every 5 seconds (matching the liveness probe periodSeconds: 5).

Files examined:

• deploy/helm/openshell/templates/statefulset.yaml — probe definitions (lines 122-135)
• deploy/helm/openshell/values.yaml — probe intervals (periodSeconds: 5 for liveness)
• crates/openshell-server/src/lib.rs — is_benign_tls_handshake_failure only matches UnexpectedEof and ConnectionReset, not InvalidData
• crates/openshell-server/src/tls.rs — TLS acceptor enforces mTLS when allow_unauthenticated is false

Root cause: tcpSocket probes are protocol-unaware — they just check port reachability. The plaintext TCP bytes fail the TLS handshake. Kubelet's httpGet probes with scheme: HTTPS would perform a proper TLS handshake, but kubelet cannot present a client certificate, so httpGet only works when gateway auth is disabled (disableGatewayAuth: true) or TLS is off entirely.

Description

Actual behavior: The gateway logs ERROR every ~5 seconds:

ERROR openshell_server: TLS handshake failed error=received corrupt message of type InvalidContentType client=10.42.0.1:18166

Expected behavior: Kubernetes health probes should not generate ERROR-level log noise.

Reproduction Steps

1. Deploy a gateway with default settings (TLS enabled, mTLS enforced)
2. Wait for the pod to become ready
3. Observe gateway logs: kubectl logs -n openshell openshell-0
4. InvalidContentType errors appear every ~5 seconds

Environment

• Kubernetes: k3s (embedded in openshell cluster container)
• Probe config: tcpSocket on port 8080, periodSeconds: 5 (liveness)
• TLS: enabled with mTLS (default)

Proposed Fix

Two-part fix:

1. Helm: Use httpGet probes (/healthz for liveness, /readyz for readiness) when client certs are not required (disableTls or disableGatewayAuth). Fall back to tcpSocket when mTLS is enforced since kubelet cannot present a client certificate.
2. Server: Add InvalidData to is_benign_tls_handshake_failure in lib.rs so the remaining tcpSocket probe errors in the mTLS case are logged at DEBUG instead of ERROR.

[github-actions]

This issue appears to have been opened without an agent investigation.

OpenShell is an agent-first project - please point your coding agent at the repo and have it diagnose this before we triage. Your agent can load skills like debug-openshell-cluster, debug-inference, openshell-cli, and generate-sandbox-policy.

See CONTRIBUTING.md for the full workflow.

[sjenning]

We could:

1. Remove the probes from the StatefulSet
2. Make the /healthz and /readyz endpoints unauthenticated
3. Create a new plain HTTP listener on a separate port just for healthz/readyz
4. Filter connection failures of this type so they don't appear in the log

I think options 2 or 3 make the most sense

[TaylorMutch]

I was just seeing the same issue while reviewing/testing #892; this definitely needs improvement.

I am inclined to start with a new plain HTTP listener mainly since it is the simplest thing (option 3 you propose), since it has specific purpose separate from the existing grpc server. If we later then have to have it utilize a TLS cert trusted by the kubelet (and expose the knobs in the helm chart to customize the readiness/liveness probes), that is additive. WDYT @sjenning ?

[sjenning]

I am leaning toward option 3 as well. I had Claude make the changes to serve the health/ready endpoints unauthenticated out of the same port, but it was not very clean.

[sjenning]

After "fixing" this, I still saw the errors in the gateway log. I think it is coming from the docker HEALTHCHECK

OpenShell/deploy/docker/cluster-healthcheck.sh

Line 82 in 8a813ab

timeout 2 bash -c 'echo >/dev/tcp/127.0.0.1/30051' 2>/dev/null || exit 1

[TaylorMutch]

I took a crack at an implementation (see this branch), interested in your thoughts.