Hacker News Reader

Comment by nijave | Hacker News Reader

You can also do sidecar proxy pattern where the the sidecar handles TLS termination (incoming or outgoing). That's basically service mesh light.

You can also use MutatingWebhooks to inject initContainers or side cars to achieve that pattern.

MutatingWebhooks increase the runtime complexity since you're jamming more config in but they can handle vendor/3rd party software.

Depending on the CNI, insecure TLS flags might not actually be that bad. There are some CNIs floating around that can handle encryption. In addition, software defined networks like AWS might not offer encryption but they do guarantee messages are authenticated so you can trust the source IP

View on HN

IMO that's ideal situation: when service does not encode any routing information and just talks to another service via fake DNS name. And actual routing is performed by infrastructure tools which can implement TLS, collect metrics, collect full HTTP logs if asked, implement retries, caching and so on. This is about outgoing connections and incoming connections.

It could also save on container size theoretically. Implementing TLS is a daunting task and requires many kilobytes of code. Implementing HTTP is easier task. So you can strip TLS implementation and achieve lighter containers.

You save shit all if every container comes with sidecar doing the actual TLS, it's extra component to debug and extra small latency added.

Or you can leverage ebpf like cillium.

In practice it's not that much. I think our Envoy sidecars take, maybe, 8mb of RAM when the apps are usually 500-1000MB. They usually add afaik <1ms latency. In addition, you can implement client side load balancing through Envoy so you can hit your services directly without intermediary load balancers.

It adds complexity with the side car but usually you get standardized RED metrics regardless of if the service implemented them.

You can also have the sidecar do connection pooling and maintain persistent or long lived TCP connections which ends up speeding things up without doing that at the app level.

> You can also do sidecar proxy pattern where the the sidecar handles TLS termination (incoming or outgoing). That's basically service mesh light.

That's a horrid idea, why would you do that ?

It’s an extremely common pattern. Decoupling TLS allows the developer to focus on the application and it makes for far easier development and testing.

Reply on news.ycombinator.com