Introduction
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.
Conclusion
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.
