Mutual TLS for service communication in Kubernetes - Step-by-Step Execution

Process Flow - Mutual TLS for service communication

Service A wants to connect to Service B

↓

Service A presents its client certificate

↓

Service B verifies client certificate

↓

Service B presents its server certificate

↓

Service A verifies server certificate

↓

Secure connection established with mutual trust

↓

Data exchange happens

This flow shows how two services authenticate each other using certificates before exchanging data securely.

Execution Sample

Kubernetes

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

This Kubernetes manifest enables strict mutual TLS for all services in the namespace.

Process Table

Step	Action	Service A State	Service B State	Result
1	Service A initiates connection	Sends client certificate	Waiting for client cert	Connection attempt started
2	Service B receives client certificate	Client cert sent	Verifies client certificate	Client authenticated
3	Service B sends server certificate	Waiting for server cert	Sends server certificate	Server cert sent
4	Service A verifies server certificate	Verifies server certificate	Server cert sent	Server authenticated
5	Mutual TLS handshake completes	Both certificates verified	Both certificates verified	Secure connection established
6	Data exchange	Encrypted data sent	Encrypted data received	Secure communication ongoing

💡 Mutual TLS handshake completes successfully, enabling encrypted and authenticated communication.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	Final
Service A Certificate	Not sent	Sent to Service B	Sent	Waiting for server cert	Verified server cert	Mutual TLS established	Secure communication
Service B Certificate	Not sent	Waiting for client cert	Client cert verified	Sent to Service A	Sent	Mutual TLS established	Secure communication
Connection State	Disconnected	Connecting	Authenticating client	Authenticating server	Handshake complete	Connected	Secure connection

Key Moments - 3 Insights

Why does Service B verify Service A's certificate before sending its own?

Service B must confirm Service A is trusted before revealing its own identity to avoid exposing sensitive data. This is shown in step 2 and 3 of the execution_table.

What happens if Service A fails to verify Service B's certificate?

The mutual TLS handshake fails and the connection is not established, preventing insecure communication. This would stop the flow at step 4 in the execution_table.

Why is mutual TLS stronger than one-way TLS?

Because both services authenticate each other, not just the server. This prevents impersonation from either side, as seen in the mutual verification steps 2 and 4.

Visual Quiz - 3 Questions

Look at the execution_table, what is the state of Service A after step 3?

A Client certificate verified

B Secure connection established

C Waiting for server certificate

D Disconnected

💡 Hint

Check the 'Service A State' column at step 3 in the execution_table.

At which step does the mutual TLS handshake complete?

A Step 4

B Step 5

C Step 6

D Step 3

💡 Hint

Look for the row where both certificates are verified and connection is established.

If Service B does not verify Service A's certificate, what will happen?

A Handshake fails and connection stops

B Service B sends server certificate anyway

C Connection proceeds without encryption

D Service A retries sending certificate

💡 Hint

Refer to the key moment about verification failure and the execution_table step 2.

Concept Snapshot

Mutual TLS (mTLS) requires both client and server to present certificates.
In Kubernetes, enable mTLS via PeerAuthentication with mode STRICT.
Services verify each other's certificates before exchanging data.
This ensures encrypted, authenticated, and trusted communication.
If verification fails, connection is refused.
Use mTLS to secure service-to-service communication in clusters.

Full Transcript

Mutual TLS for service communication means both services prove their identity using certificates before talking. Service A starts by sending its client certificate to Service B. Service B checks this certificate to make sure Service A is trusted. Then Service B sends its own server certificate back. Service A verifies it. When both sides confirm each other's certificates, they establish a secure connection. This process is called a mutual TLS handshake. After the handshake, data is exchanged securely and encrypted. If either side fails to verify the other's certificate, the connection stops. In Kubernetes, you enable this by applying a PeerAuthentication resource with mtls mode set to STRICT. This setup helps keep service communication safe and trusted inside the cluster.