We are building a secure fintech platform and need to ensure that if one pod is compromised, the attacker can't sniff traffic to other services. Is a service mesh like Istio the only way to get mTLS across a kubernetes cluster, or are there simpler NetworkPolicy alternatives?
3 answers
While a service mesh like Istio is the most robust way to enforce mutual TLS (mTLS) automatically, it adds significant complexity and CPU overhead to your kubernetes cluster. If you only need basic isolation, start with Kubernetes NetworkPolicies to restrict traffic at the IP/Port level. However, for true zero-trust where every request is encrypted and authenticated, Istio or Linkerd is the way to go. We rolled out Linkerd in 2024 because it was much lighter than Istio and gave us mTLS out of the box with zero configuration changes to our existing application code. It really simplified our compliance audit.
Are you using a CNI plugin that actually supports NetworkPolicies? Some standard kubernetes networking setups ignore them entirely, which leaves your cluster wide open.
Use Cilium as your CNI. It uses eBPF to provide high-performance security and observability for your kubernetes networking without the sidecar overhead of Istio.
Arthur's suggestion of Cilium is excellent for performance. It's often easier to manage than a full service mesh while still securing your kubernetes traffic.
We are using Calico, so NetworkPolicies should work. Scott, if I use Calico for isolation, do I still need the "encryption" part of a service mesh to be compliant with PCI-DSS? I'm trying to figure out if the kubernetes native tools are enough or if the encryption layer is a hard requirement for financial data in transit.