👋 Hi! I’m Bibin Wilson. In each edition, I share practical tips, guides, and the latest trends in DevOps and MLOps to make your day-to-day DevOps tasks more efficient. If someone forwarded this email to you, you can subscribe here to never miss out!

To understand the need for HBONE, you must look at the problem with the "Classic" Istio Sidecar model.

In classic Istio, every single application Pod has a helper container (Sidecar/Envoy) running inside it. This sidecar handles all network traffic.

If you have 1,000 pods, you have 1,000 sidecars eating up RAM and CPU.

To add the sidecar, you have to restart the application.

Sidecars often parse complex application data (HTTP headers) even when you just wanted simple encryption.

Istio developers wanted a "Sidecar-less" mode. They wanted to pull the proxy out of the pod and put it on the Node level (a shared proxy called Ztunnel).

If you move the proxy out of the Pod and onto the Node, how do you keep the identity context?

If Service A talks to Service B, and the traffic goes through a shared Ztunnel, the destination needs to know: "Did this come from Service A or Service C?" Standard TCP mTLS encrypts the traffic, but it doesn't carry extra metadata easily.

They needed a protocol that could:

HBONE was created to carry that metadata.

HBONE (HTTP-Based Overlay Network Environment) is a standard way to wrap raw TCP traffic inside an HTTP request.

It is basically how Istio safely moves traffic inside a Kubernetes cluster. Here is what it does 👇

It creates a secure tunnel that carries traffic between service proxies as illustrated in the image below.

Before HBONE, every connection from one workload to another created separate connections between sidecars. With HBONE, many connections share one secure tunnel instead.

Here is how HBONE works under the hood.

It combines three web standards.

You can stream multiple distinct TCP connections over one wire. This drastically reduces the number of expensive TLS handshakes required between components.