How to use Istio to secure mTLS traffic in Kubernetes

The challenge of securing internal communication in Kubernetes

When migrating applications to Kubernetes, the volume of internal communication between different services explodes. In practice, this means hundreds of microservices talk to each other constantly across the cluster network, often without any encryption whatsoever. If an attacker manages to breach a single container, they gain a free pass to listen to all internal network traffic, stealing passwords, tokens, and sensitive customer data. To solve this structural problem without altering application code, we rely on a technology called Service Mesh, which acts as a dedicated infrastructure layer to manage inter-service communication.

Before implementing advanced security rules, we must ensure the cluster base infrastructure is stable and has sufficient resources. In high-demand scenarios, for example, managing heavy workloads is similar to how we operate and scale GitLab runners in Kubernetes to absorb traffic spikes. With the infrastructure ready, Istio steps in by injecting a small helper program, known as the Envoy sidecar, alongside each application container. This program intercepts all network traffic, taking over the responsibility of encrypting data and validating identities.

How mTLS encryption works in practice

The core concept behind security in Istio is mTLS, which stands for mutual Transport Layer Security. On the traditional web, when you visit a secure site, only your browser verifies if the server is legitimate. With mTLS, the process is bilateral: the requesting service proves who it is to the receiving service, and vice versa, using digital certificates automatically issued by the service mesh. In practice, this means no container can pretend to be another, eliminating risks of attacks where an impostor intercepts internal calls by posing as a database or a critical microservice.

To manage this entire process of issuing and automatically renewing certificates without headaches, Istio uses an internal tool called Istiod. It acts as a certificate authority distributing short-lived cryptographic keys to the Envoy proxies. This dynamic resembles organizing complex CI/CD pipelines, where automation handles repetitive tasks so the team can focus on business logic. Furthermore, just as we optimize storage to ensure builds occur without bottlenecks, as explained in our tips on how to speed up Docker builds with cache mounts, Istio ensures cryptographic overhead is minimal and highly optimized at the proxy level.

Configuring Istio to enforce strict policies

By default, when we install Istio, it typically operates in a permissive mode. This means the mesh accepts both encrypted connections and legacy unencrypted traffic, facilitating gradual adoption. However, to achieve a real security posture, we need to change this policy to strict mode. When strict mode is set, any communication attempt that does not use mTLS is immediately rejected by the recipient's proxy, ensuring no plaintext traffic circulates within the cluster's internal network.

Below is an example configuration file in YAML format that applies this strict security policy across your Kubernetes cluster's production namespace. Remember to review selectors to ensure the rule scope covers exactly the desired services:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT

Applying this rule requires care to avoid disruptions in legacy services that might not be ready yet. It is advisable to test in isolated environments and verify that regulatory compliance and security guidelines—similar to the requirements we cover when auditing NR 1 security in cloud microservices—are strictly met before flipping the switch in production.

Validating security and troubleshooting common issues

After applying the strict mTLS policy, the next essential step is to validate that traffic is truly secure and that no legitimate application broke. Istio offers powerful command-line tools, such as the istioctl command, which lets you inspect connection status and verify that certificates are synchronized correctly across pods. In practice, you can run quick checks to ensure the encrypted tunnel is active across all critical routes in your microservice ecosystem.

Below is a useful command to check the current mesh state and diagnose potential authentication failures between services in your cluster:

istioctl proxy-config secret <pod-name>.<namespace>

If you notice TLS handshake errors in the Envoy proxy logs, verify that all involved workloads have the sidecar correctly injected. Maintaining routine automated tests and constant monitoring prevents unpleasant surprises during maintenance windows or infrastructure updates.

Conclusion

Implementing end-to-end encryption with Istio Service Mesh transforms the security of Kubernetes-based architectures, elevating protection against internal intrusions. Although it requires planning and careful transition from permissive to strict mode, the gains in compliance, data shielding, and reliability vastly outweigh the operational effort. Adopting these practices ensures your infrastructure is ready for modern cloud security challenges.

In short, investing in a robust service mesh shields your microservices against unwanted lateral movement across the network. By combining strict mTLS policies with active monitoring and continuous automation, you build a resilient, secure environment ready to scale smoothly and predictably.