mTLS and non-HTTP service

I’ve installed Linkerd on minikube and successfully got it protecting HTTP traffic with mTLS. However, I also have a simple SQL database running in a pod that talks a non-HTTP protocol over TCP. I understand from the docs that Linkerd 2 can’t (yet) automatically apply mTLS to this service. But is there any way I can manually configure the client to make a TLS connection itself and have the Linkerd proxy terminate that TLS connection and forward on the protocol traffic?

@neilmadden, thanks for the question.

This sounds more like a use case for an Ingress Controller or reverse proxy. The Linkerd proxy is configured to do mTLS from the control plane, which issues the certificate. So, the client can initiate the TLS connection, but Linkerd can’t decrypt and pass on that traffic.

You could accomplish this with an IngressController, but that would have to then send the request to the database, unencrypted.

Sorry, I don’t think I explained the situation well enough. The database and the client are both running in pods within the same namespace, with Linkerd sidecar proxies injected into both. If they were talking HTTP then Linkerd would have automatically added TLS, but because they are talking a custom TCP protocol it doesn’t. My question is whether I can manually make a TLS request to the linkerd proxy sidecar in the database pod - e.g. if I configure the cient to trust the Linkerd trust root certificate.

(NB: I don’t need mTLS, just normal TLS is fine, so I don’t mind if there’s no client cert involved).

@neilmadden, with the default configuration, requests to a pod injected with the Linkerd proxy are handled by the proxy.

As you’ve discovered, part of that handling the request includes protocol detection and the non-HTTP request from the SQL client will not be encrypted. If the client encrypts the request, then Linkerd will detect that and proxy it on with byte level metrics.

I haven’t heard of anyone attempting to use the Linkerd trust root for their own clients, and I suspect that it either won’t work or that it will be difficult to set up and maintain. The client service will require that the Linkerd Identity component is available in order to get a certificate, and that Identity API isn’t considered “public” API.

The roadmap items for the 2.7 release include encryption for all TCP traffic, and we hope to have that released soon. You can follow the progress here:

To add my two cents, @neilmadden I don’t think what you’re proposing is impossible, but it’s probably a little fragile. I’d suggest making a TLS connection from your client directly to the database for now, if that’s easy–Linkerd will treat it as a TCP connection and just proxy it without doing anything fancy. (Assuming the DB server supports this.)

Once 2.7 ships, hopefully before EOY, you’ll be able to just rely on Linkerd for this without having to do it in the client.

Let me know if that makes sense.