Trong thời đại hệ thống chuyển dịch từ monolith sang microservices, từ datacenter lên Kubernetes, và từ intranet sang zero-trust networking, câu hỏi lớn nhất mà mọi kiến trúc sư phải trả lời luôn là:

Làm sao để các service có thể tin nhau trong một môi trường mà không thể tin tưởng vào mạng nội bộ?

Câu trả lời chính là mTLS – mutual TLS.

Hầu hết các công ty lớn như Google, Netflix, Lyft, Grab, Shopee đều sử dụng mTLS làm lớp bảo mật mặc định cho traffic giữa các microservice.
Trong Service Mesh như Istio, Envoy, Linkerd, mTLS gần như là bắt buộc.

Hôm nay chúng ta sẽ đi sâu vào khái niệm, cơ chế hoạt động, lợi ích, rủi ro, best practices, và xem mTLS được triển khai thế nào trong Service Mesh và trong hệ thống không dùng mesh.

1. TLS vs mTLS – sự khác nhau

Hầu hết lập trình viên đều quen thuộc với HTTPS (TLS).
Nhưng TLS thông thường chỉ xác thực 1 chiều:

• Client → kiểm tra certificate của server
• Server không biết client là ai

Ví dụ:
Browser truy cập Google.com → browser xác thực Google.
Nhưng Google không xác thực bạn (về mặt certificate).

mTLS làm gì thêm?

Server và client xác thực lẫn nhau bằng certificate.

• Client phải chứng minh danh tính (ai là người đang gọi?)
• Server phải chứng minh danh tính (đã đúng service chưa?)
• Traffic được mã hóa end-to-end
• Không một service giả mạo nào có thể lọt qua

2. mTLS hoạt động như thế nào? (Cơ chế chi tiết)

Dưới đây là luồng handshake mTLS đầy đủ:

Bước 1: Server gửi certificate

Chứa:

• Public key
• Tên service
• CA đã ký
• Thông tin hạn dùng

Client kiểm tra certificate bằng CA root → nếu hợp lệ → tiếp tục.

Bước 2: Client gửi certificate của chính nó

Tương tự server:

• Public key
• Identity (ví dụ: service-account/name)
• CA ký

Server cũng dùng CA để xác thực client.

➡ Trái tim của mTLS nằm ở mutual authentication.

Bước 3: Hai bên thỏa thuận session key

Sử dụng Diffie–Hellman hoặc ECDHE để tạo secret key cho phiên làm việc.

Không ai ngoài hai bên có thể giải mã traffic.

Bước 4: Traffic truyền qua kênh được mã hóa & xác thực

Từ đây, tất cả data đều:

• mã hóa (confidentiality)
• có checksum chống giả mạo (integrity)
• từ đúng nguồn hợp lệ (authentication)

3. Tại sao mTLS quan trọng?

Trong microservices, bạn thường có:

• hàng trăm service
• chạy hàng ngàn pod
• trong một cluster chứa nhiều team
• networking phức tạp
• CI/CD liên tục

Bạn không thể tin rằng traffic nội bộ là an toàn.
Không thể tin vào IP.
Không thể tin firewall sẽ bảo vệ tất cả.

👉 Bạn phải tin vào danh tính của service, không tin vào network.

mTLS cung cấp 3 lớp bảo mật:

✔ Encryption

Traffic không thể bị lộ.

✔ Authentication

Server và client phải chứng minh danh tính.

✔ Integrity

Không ai có thể chỉnh sửa gói tin giữa đường.

4. Triển khai mTLS trong Service Mesh (Istio / Envoy)

Service Mesh là nơi mTLS phát huy tối đa sức mạnh.

Istio sử dụng kiến trúc Sidecar Envoy

Khi bạn deploy một service:

Service A (container)
Envoy sidecar

Toàn bộ traffic đi qua Envoy, không đi trực tiếp vào container.

Envoy làm gì?

• Tạo & rotate certificate tự động (thường mỗi 12 giờ)
• Xác thực certificate của service khác
• Áp policy mTLS (STRICT / PERMISSIVE)
• Thực hiện retry, timeout, circuit breaking
• Gắn trace ID

Istio control plane (Istiod) làm gì?

• Cấp certificate (CA)
• Refresh/rotate certificate
• Đồng bộ chính sách mTLS
• Gắn danh tính service qua SPIFFE ID
  Ví dụ:spiffe://cluster.local/ns/default/sa/payment-service

Ví dụ bật mTLS STRICT trong Istio

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

➡ Từ nay trở đi, mọi traffic nội bộ bắt buộc phải dùng mTLS.

Không certificate → chặn ngay.

5. Triển khai mTLS mà không cần Service Mesh

Một số cách phổ biến:

✔ NGINX Ingress

ssl_verify_client on;
ssl_client_certificate /etc/nginx/ca.crt;

✔ Spring Boot

server.ssl.client-auth=need
server.ssl.key-store=server-keystore.p12
server.ssl.trust-store=truststore.p12

✔ Envoy standalone

validation_context:
  trusted_ca:
    filename: /etc/certs/ca.crt

Vẫn mTLS đầy đủ nhưng phải quản lý certificate thủ công, không scale tốt bằng mesh.

6. Rủi ro khi triển khai mTLS

Nếu làm sai, mTLS có thể gây downtime toàn hệ thống:

❌ Certificate hết hạn → service chết hàng loạt

Rất nhiều công ty đã bị outage vì certificate expire.

❌ Rotate không đồng bộ

Service A có certificate mới
Service B CA cũ → reject
👉 Tất cả request fail

❌ Private key bị lộ

Xem như toàn bộ hệ thống mất an toàn.

❌ DevOps quên update CA ở gateway

All traffic bị chặn.

Service Mesh giúp giảm 95% rủi ro này:

• Tự rotate certificate
• Tự cấp CA
• Tự đồng bộ
• Tự bật mTLS
• Không cần dev tự quản lý key

7. Best Practices khi dùng mTLS

1) Đừng tự quản lý certificate nếu không cần

Hãy dùng:

• Istio Citadel
• Vault PKI
• AWS ACM PCA
• Consul CA

2) Mỗi service phải có danh tính duy nhất

Thông qua:

• SPIFFE ID
• service account
• workload identity

3) Rotate certificate liên tục

Best practice: 24h hoặc 12h.

4) Bật STRICT mode

PERMISSIVE mode rất nguy hiểm.

5) Monitor certificate expiry

Luôn cảnh báo trước 7 ngày, 3 ngày, 1 ngày.

6) Log mọi TLS handshake

Đặc biệt trong microservices khi debugging.

8. So sánh TLS vs mTLS (Bảng tóm tắt)

Tiêu chí	TLS	mTLS
Xác thực server	✔	✔
Xác thực client	❌	✔
Bảo vệ nội bộ	Thấp	Rất cao
Zero-trust	Không	Có
Triển khai	Dễ	Khó hơn
Mesh tự động hỗ trợ	Không	Có

9. Phỏng vấn System Design – mTLS thường được hỏi gì?

1. Why do we need mTLS in microservices?

➡ Vì mạng nội bộ không đáng tin; cần xác thực service-to-service.

2. How does mTLS differ from TLS?

➡ mTLS xác thực 2 chiều.

3. How does Istio implement mTLS?

➡ Envoy sidecar + SPIFFE ID + automatic certificate rotation.

4. How do we rotate certificates safely?

➡ Overlap window, CA chain management, automated renewals.

5. What happens if certificate is expired?

➡ Traffic bị chặn → system outage.