How Istio Ensure the Security of Inter-Service Communication?

Photo by Markus Winkler on Unsplash


In this post, I will summarize at an overview level how Istio guarantees the security of inter-service communication and how it guarantees it.

What we exactly want to secure in inter-service communication and the conventional security model ?

What we want to secure as inter-service communication is
to control the access source that communicates and protect it from attacks such as eavesdropping, spoofing, and falsification.
in short:

  • Defense against man in the middle attacks
  • Access control

Is listed as a security requirement. As a conventional security model, these have been secured by constructing a private network and restricting access sources on an IP basis

What approach did Istio take?

In today’s container-based systems, IP addresses change frequently and dynamically, so this approach breaks down. Therefore, Isito decided to define an ID for each workload and perform access control based on the ID. What kind of approach is it specifically?

Core concept

Authentication and encrypted communication are performed by TLS communication based on the ID assigned to the workload, and access control is realized by performing authorization control for the authenticated ID.
For that purpose, the following mechanism is implemented:

  • Assign a unique ID to the workload
  • Issuance, distribution and rotation of certificates to authenticate IDs

These are defined in a standard specification called SPIFFE (Secure Production Identity Framework For Everyone), and Istio is an implementation that the Citadel component follows. The specific SPIFEE specifications and flow are clearly mentioned in SPIFFE and its implementation, SPIRE .

In other words, there is an isdiod (Citadel) that plays the role of a certificate authority for issuing and registering IDs and certificates for workloads, and the istio-agent that exists on each node is called this Citadel. It mediates exchanges between istio proxies and distributes certificates. (This agent is in charge of SDS of istio proxy) This puts a load on istiod because the pod itself is divided and governed by the istio agent even in a large cluster with a large number of pods. It can be suppressed considerably.

Also, unlike the normally expected TLS, this certificate has a very short expiration date and is frequently rotated. As a result, the attacker must steal this certificate every time it is rotated in order to continue the attack, increasing the difficulty of the attack.


In this way, Istio authenticates at the workload level and provides access control for each. As a result, secure communication can be realized in any environment regardless of the platform on which it is running.

 by the author.




DevOps Consultant. I’m strongly focused on automation, security, and reliability.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

What is NAC ?

The Seekers — Official Mint Guide

Hesitation in Purchasing Cybersecurity

Lunaray Token Security Scan Report

SafeMore Presale Info

The power of big data: prosperous or devastating to human society?

Data Privacy Is a Human Right

A privacy talk with WhatsApp co-founder Brian Acton

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


DevOps Consultant. I’m strongly focused on automation, security, and reliability.

More from Medium

Deploy and use ArgoCD with Portainer (part 2)

How to safely drain the k8s node!

Kubernetes monitor using Prometheus and Thanos , (2)Deployment

Kubernetes Analogy Series: Authentication vs Authorization vs Admission Controller