How do service meshes work?

How do service meshes actually work?

Fundamentally, service meshes are implemented using so-called sidecars. The most prevalent sidecar is probably Envoy. In essence, sidecars are separate containers that proxy network communication from services. Sidecars observe, control, and often encrypt the network communication between services.

Sidecars form the data plane of service meshes. The other part of a service mesh, the control plane, manages and configures the sidecars to balance load, enforce policies, and collect stats.

Ok, you said sidecars "encrypt the network communication between services", can't we then just put our services into secure enclaves and be done with it?

Glad you asked! Unfortunately, in the context of confidential computing, that wouldn't help much. Briefly, there are two main reasons:

1. Encrypted service-to-service communication needs to terminate inside secure enclaves instead of separate sidecars. Otherwise an attacker could just tap the service-to-sidecar communication, manipulate the sidecar, etc.

2. A crucial aspect of confidential computing is verifiability. Someone needs to make sure that each service in the cluster is actually running inside secure enclaves and that it was initialized with the right parameters and code.

In particular, the second reason requires careful design and thought. Of course there is also much more to consider like "what happens in case of failures or updates?" or "How does the user of the app know that everything is alright without jumping through 10,000 hoops?".

By now, we hope to have convinced you that confidential computing is useful, that services meshes are useful, and that we clearly need a dedicated service mesh for confidential computing --- just like Marblerun.

In the next and final episode of this series we're going to dig deeper into the requirements for a service mesh for confidential computing and give an intro to the design of MarbleRun. See you soon!