Do One Thing Well: Why We Don't Parse Database or Kubernetes Protocols

When building an infrastructure access platform, the temptation to “proxy everything” is overwhelming. Once you have a working reverse tunnel architecture, a robust identity-aware proxy, and an automated Certificate Authority, the feature requests write themselves.

“Can you route psql through it?” “What about kubectl?” “Can you just put an HTTP reverse proxy in front of our internal web apps?”

We said yes to the last one. Application access reuses the same reverse tunnels, Certificate Authority, and identity model we already built for SSH, so forwarding an internal HTTP or TCP service down that tunnel and stamping it with a signed identity assertion costs us almost nothing extra. psql and kubectl are a different problem: supporting them means terminating and parsing an entirely new wire protocol inside the control plane, and we deliberately chose not to build that.

Here is a technical breakdown of why we draw the line at bespoke database and Kubernetes protocol parsing — not at “SSH and nothing else” — to keep Mezite simple, secure, and auditable.

The All-in-One Complexity Trap

When a single platform attempts to proxy SSH, PostgreSQL, Kubernetes, and HTTP, it inevitably compromises on the security and performance of each.

Consider the protocol level. SSH is a multiplexed binary protocol. HTTP is fundamentally different. PostgreSQL has its own wire protocol, complete with complex startup messages and SSL negotiation quirks. Kubernetes API traffic is essentially HTTPS, but involves WebSockets and SPDY for interactive commands like kubectl exec.

To proxy all of these effectively, your control plane must become a monolithic protocol parser. It must inspect traffic, handle protocol-specific routing, manage disparate authentication mechanisms, and buffer disparate data streams.

This monolithic approach breaks our core engineering principles:

1. Massive Attack Surface: Every protocol parser you add introduces edge cases, parsing bugs, and potential vulnerabilities. A vulnerability in the database proxy logic should not risk compromising your SSH access.
2. Lowest Common Denominator Security: When you generalize access, you lose protocol-specific hardening. For SSH, we want PTY-level session recording at the edge. For databases, you want SQL query parsing. Trying to fit both into a single agent architecture results in a diluted security posture.
3. Operational Friction: A proxy that handles everything becomes a massive dependency. When it fails, you lose access to your servers, your databases, and your orchestrators all at once.

Doing One Thing Well: The SSH Advantage

By stripping away database and Kubernetes protocol parsing, we keep Mezite’s control plane built around one thing: the OpenSSH protocol, plus the reverse-tunnel and Certificate Authority primitives that application access also builds on. This focus yields compounding technical benefits.

Edge Session Recording

As we discussed in a previous post, when the Mezite agent (mezd) is present, we implement session recording at the PTY level directly on the target node — agentless OpenSSH nodes, which have no mezd to record on, fall back to best-effort recording at the proxy instead. Node-mode recording is only possible because the agent acts as a dedicated SSH server for these sessions. If that same channel-handling logic also had to parse PostgreSQL’s wire protocol or intercept Kubernetes API calls, the architecture becomes significantly more complicated, and we risk losing the ability to capture a clean terminal stream before it is multiplexed.

The Certificate Authority Architecture

Our security model is built around short-lived SSH certificates signed by CA keys that use ECDSA P-256. We generate these certificates automatically, and OpenSSH natively understands them.

If we expand into database access, we have to deal with the fact that PostgreSQL does not natively support SSH certificates. We would need to manage X.509 client certificates, map them to database roles, and handle completely different revocation mechanisms. Kubernetes has its own RBAC and authentication webhook system.

By staying out of the database- and Kubernetes-protocol business, our CA infrastructure remains simple, fast, and bulletproof. The User CA signs SSH certificates. The Host CA signs host certificates. The trust boundary is absolute.

The Single-Port ALPN Routing

Our proxy (mezhub) can multiplex HTTPS for the web UI, gRPC for the agent API, and reverse tunnels — including SSH and application traffic — over a single port using TLS Application-Layer Protocol Negotiation (ALPN).

Because we don’t have to route PostgreSQL or Kubernetes API traffic through it, that routing logic stays lean. We don’t need to deeply inspect payloads to guess whether a connection is meant for a database or a container orchestrator — the client’s ALPN identifier already says which virtual listener it wants. The proxy simply shuttles encrypted bytes to the right one. It remains a high-throughput router, not a protocol interpreter.

Conclusion

Complexity is the enemy of security. In a self-hosted access platform, the code you ship runs directly inside the customer’s network. It must be impenetrable.

We believe that SSH access is the foundation of infrastructure management, and it deserves a dedicated, uncompromising tool. The boundary we draw isn’t “SSH and nothing else” — it’s no bespoke database or Kubernetes protocol parsing. By rejecting that scope explicitly, Mezite stays a minimal, lightning-fast single binary built around the reverse-tunnel and certificate primitives that power secure, audited SSH access — and the application access layered on top of it.

---