Using linkerd2 for mTLS only with DNS service discovery (or custom service discovery)

[ElvinEfendi]

Our simplified routing infrastructure is pod1 -> gateway -> pod2. All actors can potentially be in different k8s clusters and cloud regions. Connectivity between them is assumed.

I'd like to leverage Linkerd to provide end to end encryption and workload identity. Thus, I have following questions:

1. Can I install only linkerd-proxy, proxy injector and identity and nothing else?
2. Can I make linkerd-proxy to operate at TLS level only and do nothing else?
3. Can I configure linkerd-proxy to always do mTLS if asked regardless whether destination is in the mesh or not?

With these done, the above request path would become:
pod1 | linkerd-proxy -> gateway -> linkerd-proxy | pod2

The gateway would require TLS client certificate and linkder-proxy would provide it. Gateway will authenticate the cert because of the shared anchor certificate.
Similarly when gateway connects to pod2's linkerd-proxy, linkerd-proxy would require TLS client certificate and gateway would provide it.

[olix0r]

The short answer is: no, not without code changes.

Can I install only linkerd-proxy, proxy injector and identity and nothing else?

The destination controller is required to communicate the expected identity of the target pod to clients. I.e. if the gateway is connecting to pod 2, how does the proxy discover what the expected identity is? The destination controller is responsible for providing this information.

Can I make linkerd-proxy to operate at TLS level only and do nothing else?

You should be able to configure linkerd to treat all traffic as opaque so that HTTP detection is not performed. The destination controller is required to provide these hints, though.

Can I configure linkerd-proxy to always do mTLS if asked regardless whether destination is in the mesh or not?

You can configure proxies to require identity on inbound traffic, though there are a number of caveats here--especially with regard to Kubernetes liveness/readiness probes, which cannot be secured.

On the outbound side, mtls requires knowing the identity of the target pod. So, if you're communicating with an unmeshed pod, there is no identity. So, I guess the question is: can you configure proxies to fail to communicate with unmeshed endpoints? This would require code changes but is a reasonable feature request.

[ElvinEfendi]

You should be able to configure linkerd to treat all traffic as opaque so that HTTP detection is not performed. The destination controller is required to provide these hints, though.

Would it be still doing mTLS in opaque mode?

I.e. if the gateway is connecting to pod 2, how does the proxy discover what the expected identity is?

On the outbound side, mtls requires knowing the identity of the target pod

by identity of the target pod, are you referring to the public leaf certificate target pod has? Here's what I had in mind:

pod1 talking to pod2, and they are not necessarily in the same mesh but they both share the same PKI / anchor certificate. So when pod1 starts TLS handshake against pod2, it verifies the legitimacy of pod2 based on the TLS anchor certificate it has. The same way browsers verifies authenticity of a website using public CA's they trust. pod1 would also verify that the certificate pod2 uses covers the server name (target service fqdn). What am I missing?

[olix0r]

Linkerd's certificates are not tied to service names, but rather to the pod's ServiceAccount (since the service account token is used to bootstrap the identity certificate). This enables linkerd to work with arbitrary pod-to-pod communication. Furthermore, since service membership is generally dynamic (that is, a pod can exist in an arbitrary number of services that can change at runtime), the certificates do not need to be updated as these memberships change.

There's a brief overview of the mesh tls system at https://linkerd.io/2.11/features/automatic-mtls/