Hello everyone! This blog accompanies you on your MSA journey. Today, we’re going to delve deep into the ‘trust’ issue that you’ve probably encountered at some point when operating microservices in a Kubernetes environment.
In a cluster where countless services are floating around chaotically, how can Service A trust and communicate with Service B? It’s like spies in a movie needing to verify each other’s identities. π΅οΈββοΈ
How does Istio solve this complex identity verification problem? The key to that secret lies in SPIFFE.
π€ Problems with the Traditional Approach: “I don’t trust IP addresses!”
In the past, firewall rules were set up based on server IP addresses to identify each other. It was like, “A request from 10.0.1.10 must be the ‘payment service’. Let’s allow it!”
However, in the era of containers and Kubernetes, this approach no longer works.
- Dynamic IP Addresses π: Pods can die and be reborn at any time, and their IP addresses change each time. IP addresses can no longer serve as a fixed identity.
- Security Vulnerabilities π: How can pods deployed on the same node trust each other? With only IP addresses, it’s difficult to distinguish between a genuine ‘payment service’ and a malicious pod impersonating it.
Ultimately, we need to focus not on “where” a request came from, but on “who” it is. This is the moment the concept of Workload Identity emerges.
β¨ The Savior Appears: Secure Production Identity Framework for Everyone, SPIFFE
SPIFFE (Secure Production Identity Framework for Everyone), as its name suggests, is a ‘framework’ and ‘standard specification’ for assigning secure and standardized identities to all workloads. It’s not a specific software, but rather a promise that “a workload’s ID card must be in this format, and it must be issued and verified in this way.” π
Istio adopts this SPIFFE standard to assign unique identities to all workloads within the service mesh.
Key Components of SPIFFE βοΈ
- SPIFFE ID: This is the unique ID number for a workload. It is expressed in URI format and has the following structure:
- trust-domain: This refers to a trusted domain, which is a security boundary. It typically represents a single Kubernetes cluster. (e.g., cluster.local)
- workload-identifier: This is the path that uniquely identifies the workload within that domain. (e.g., /ns/default/sa/my-app-sa)When combined, they look like this.Now, this ID will point to a workload using the my-app-sa service account in the default namespace of the cluster.local cluster, anywhere in the world.
- spiffe://cluster.local/ns/default/sa/my-app-sa
- spiffe:///
/
- SVID (SPIFFE Verifiable Identity Document): This is the ‘physical ID card’ that proves a SPIFFE ID. This document contains the workload’s SPIFFE ID, expiration time, and other information, encrypted and signed. If someone asks, “Is your SPIFFE ID spiffe://… correct?”, you show the SVID to prove it. π
- SVIDs can be issued in two forms:
- X.509-SVID: This is the familiar form of an SSL/TLS certificate. It is primarily used for mTLS (mutual TLS) communication between services.
- JWT-SVID: This is in the form of a JWT (JSON Web Token). It can be used for user authentication at the application level, among other things.
βοΈ How Does Istio Implement SPIFFE? (A Look at the Overall Process)
So, how does Istio actually implement the SPIFFE standard and issue identity documents (SVIDs) to workloads?
- Pod Creation & Sidecar Injection π: When a new pod is created, Istio’s sidecar proxy (Envoy) is injected along with it.
- Identity Proof Request π: The sidecar proxy requests istiod, Istio’s control plane, to “issue me an ID card!” At this time, it sends information such as a Kubernetes Service Account token to prove its identity.
- Identity Verification & SVID Issuance π§: istiod acts as a CA (Certificate Authority). It verifies the service account token of the requesting proxy and generates a SPIFFE ID based on it. (e.g., spiffe://cluster.local/ns/prod/sa/payment-service)
- SVID Delivery & mTLS Communication π€: istiod delivers the X.509-SVID (certificate) containing the generated SPIFFE ID to the sidecar proxy. Now, this proxy has its ‘ID card’. When communicating with other services, they exchange these SVIDs to verify identities and establish a secure mTLS communication channel.
All these processes happen automatically without developer intervention. This is the power of a service mesh! πͺ
β Why Aren’t Other Methods the Right Answer?
Other methods besides SPIFFE could be considered. But why didn’t Istio choose them?
- Simple JWT Token Usage π:
- Why not? While JWT is an excellent authentication method, it is not a standardized identity system in itself. Without unified conventions on what information to include, who issues it, and how to verify it, each system would implement it differently, leading to reduced compatibility and scalability. SPIFFE defines all of this as a standard.
- Cloud Provider’s IAM (Identity and Access Management) βοΈ:
- Why not? AWS IAM, Google Cloud IAM, etc., are tied to specific cloud platforms. In multi-cloud or hybrid cloud environments, it’s difficult to manage workload identities consistently. SPIFFE provides a platform-neutral standard, allowing identities to be managed in the same way across any environment.
- OAuth 2.0 π‘οΈ:
- Why not? OAuth 2.0 is primarily focused on delegating user ‘permissions’. It’s suitable for scenarios like “Do you allow this app to access Google Photos on your behalf?” The focus is different from the ‘identity’ problem of proving who a workload itself is.
In conclusion, SPIFFE perfectly aligns with Istio’s philosophy because it is a powerful, standardized, and platform-neutral framework focused on workload ‘identity’.
Now, your microservices can trust and communicate securely with each other not through unstable IP addresses, but through SPIFFE, an unforgeable identity document. π
Leave a Reply