End-to-End Encryption between Hosts

[SantoDE]

Proposal

Implementing mTLS between Hosts, rather than between pods. This would require to route a connection between two maesh proxies (one per node), instead of only one (on the target node) today. That would still bring mTLS between nodes in the cluster, but not when pods are running on the same node.

Background

One of the benefits by introducing a Service Mesh is the possibility to have end-to-end encryption (mtls) between services. While Maesh is currently not build to have one sidecar proxy per service to be light-weight, we're not intending to change that. In our opinion, end-to-end encryption between hosts in a service-mesh is sufficient.

[nbyl]

This sounds like a reasonable idea to implement this kind of security. This leaves essentially two options:

• Leave the host-to-host encryption to the cluster implementation.
• Implement this in maesh. Maybe you could leverage wayguard as encryption solution in a way similar to gravitational/wormhole.

[gravypod]

Is there a use case where it's more advantageous to implement mTLS at the service mesh layer when it can be implemented at the CNI layer? For my cluster I use WeaveNet to supply full network encryption transparent to all of my services which encrypts TCP and UDP traffic.

[dtomcej]

@gravypod Great question.

If you are not using a CNI plugin that allows for encryption, or you may only want certain traffic encrypted, you may want to offload encryption to the service mesh.

The other situation is where you want to protect traffic from one service from being visible from another service inside your mesh. In that case, encrypting at the network level doesn't help, because all traffic is decrypted for network members.

[johanbrandhorst]

Not sure I'm understanding the full scope here, but if you're looking for mTLS between Go applications, you could evaluate https://github.com/johanbrandhorst/certify which automates this, given an existing CA with an API (Vault PKI, CFSS, etc). Not sure if this would be appropriate for this use case.

Disclaimer: I'm the author of certify.

[gravypod]

@jbdoumenjou most software isn't written in Golang and an in-application solution for this sort of thing is very limiting. For example, in development you might not want to use mTLS for debugging reasons. Having an out-of-code solution for this sort of thing is ideal in my yes. From @dtomcej 's comment it's clear that there exists a use case that is fairly well reasoned at an application-level that would benefit from this feature.

[johanbrandhorst]

@jbdoumenjou most software isn't written in Golang and an in-application solution for this sort of thing is very limiting.

I think there's a misunderstanding - I was suggesting the use of certify within the scope of maesh, an application that is built in Go.