Who will protect my service? Istio’s Two Strict Identity Verification Methods 🕵️‍♂️

In a complex microservices (MSA) environment, countless services communicate with each other. At this point, a question arises:

“Can I trust that entity that just sent a request to my service?” 🤔

Just like the front door of our house, we shouldn’t let just anyone in. Istio, a leading service mesh, has a very strict and systematic ‘identity verification’ system to solve such security problems. These are Peer Authentication and Request Authentication.

Let’s delve into how these two methods protect our services safely, along with an overall picture.

[image 1 — download failed]

---

🗺️ First, the Big Picture: Who is the Authentication For?

The easiest way to understand Istio’s authentication strategy is to distinguish ‘who’ the authentication target is.

1. Service 🤝 Service (Machine-to-Machine Communication): Can internal services trust each other and communicate?
2. User 👩‍💻➡️ Service (Human/External System Communication): Can we trust requests sent by end-users or external systems using the service?

Istio provides different authentication methods for these two scenarios. This is the key difference between Peer Authentication and Request Authentication.

(Source: istio.io)

---

1️⃣ Peer Authentication: “We speak in code among ourselves” 🤫

This is an authentication method used when workloads (pods, services) within the service mesh communicate with each other. In other words, it ensures the trustworthiness of Service-to-Service communication.

It’s like agents in a spy movie exchanging a password to verify each other. This password is mutual TLS (mTLS).

✨ How does it work? (mTLS)

mTLS is a method where the client and server present certificates to each other to verify their identities.

1. The reviews service sends a request to the ratings service.
2. Before communication begins, reviews and ratings exchange certificates issued by Istio.
3. They verify that each other’s certificates are valid, and once identities are proven, a secure encrypted tunnel (TLS) is created. 🔒
4. All communication content is encrypted and securely transmitted through this tunnel.

Let’s look at the YAML code

You can enforce mTLS in a specific namespace through the PeerAuthentication policy.

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: "default"
  namespace: "production" # Apply to 'production' namespace
spec:
  mtls:
    mode: STRICT # Only mTLS communication allowed!

• mode: STRICT: This means “No communication allowed for anyone who doesn’t know the password (mTLS)!” All services in the production namespace must communicate only via mTLS. Plain text (HTTP) requests will be blocked.
• mode: PERMISSIVE: This mode allows both mTLS and plain text communication for compatibility with existing services. It is useful when gradually introducing mTLS.

---

2️⃣ Request Authentication: “May I see your ID (JWT)?” 🎟️

This is used at the service mesh’s entry point (Ingress Gateway) to authenticate requests sent by end-users or external systems.

It’s like checking tickets at the entrance of a concert hall. The standard digital ticket used here is a JWT (JSON Web Token).

✨ How does it work? (JWT)

A JWT is an encrypted token containing user information (who they are, what permissions they have, etc.) and a signature.

1. The user obtains a JWT from the authentication server through login.
2. The user includes this JWT in the HTTP header (e.g., Authorization: Bearer ) every time they request an API.
3. The Istio Ingress Gateway validates whether this JWT is valid according to the RequestAuthentication policy.
4. If the signature is valid, not expired, and the issuer is trusted, the request is forwarded to the internal service.

Let’s look at the YAML code and Raw data

The RequestAuthentication policy specifies the JWT issuer and the public key (JWKS) location.

apiVersion: security.istio.io/v1
kind: RequestAuthentication
metadata:
  name: "jwt-example"
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  jwtRules:
  - issuer: "https://accounts.google.com" # JWT issuer
    jwksUri: "https://www.googleapis.com/oauth2/v3/certs" # Public key location

This policy means that for requests coming into istio-ingressgateway, it checks for a JWT whose issuer is .

– Sample JWT Raw Data:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2V4YW1wbGUuY29tIiwic3ViIjoidXNlcjEyMyIsImV4cCI6MTY3ODg4NjQwMCwiZW1haWwiOiJ0ZXN0QGV4YW1wbGUuY29tIn0.SIG_PART

(The above token consists of 3 parts: Header.Payload.Signature)

– Decoded Payload:

{
  "iss": "https://example.com",
  "sub": "user123",
  "exp": 1678886400,
  "email": "test@example.com"
}

Istio examines the contents of this Payload to verify if the iss (issuer) matches the policy, if the exp (expiration time) has not passed, and so on.

---

🤔 Common Misconceptions Debunked

• “Can’t I just authenticate with an API Key?”
• API Keys are primarily used to identify ‘which application’ made a request. In contrast, JWTs can contain much richer information, such as ‘which user’ made the request and what their role is, making them more suitable and standard for user-centric authentication.
• “Isn’t it safe for services to just communicate via HTTP within the internal network?”
• Absolutely not! 🙅‍♂️ According to the ‘Zero Trust’ security model, internal networks should not be implicitly trusted. If one service is hacked, the attack can spread to all other internal services through that compromised service. Peer Authentication (mTLS) is the most crucial defense line to prevent such internal spread.

🏁 In Summary

Let’s summarize Istio’s two authentication methods once again.

• Peer Authentication: Encrypts service-to-service communication with mTLS and verifies each other’s identities. (Strengthens internal security 🛡️)
• Request Authentication: Validates end-user requests with JWT to allow only authorized users access. (External boundary security 🚪)

These two authentication mechanisms work together to build a robust, multi-layered defense system that blocks both external intrusions and unauthorized internal access. Upgrade your service security with Istio!