..

mesh series: mTLS mechanism with envoy

Overview

지난 포스팅에서 Envoy가 80 패킷을 가로채 443으로 업그레이드하는 과정을 살펴봤다. 그런데 여기서 핵심적인 질문이 남는다.

“Envoy가 사용하는 인증서는 누가 주는 걸까? 그리고 수신측 사이드카는 이 인증서를 어떻게 믿는 거지?”

단순히 패킷을 암호화하는 것을 넘어, 서로가 서로를 신뢰할 수 있게 만드는 mTLS(Mutual TLS)와 Istio의 신뢰 구축 매커니즘을 파헤쳐 본다.

신뢰의 기원: Istiod와 CA

사이드카가 스스로 인증서를 생성하는 것은 아니다. Istio 시스템의 관제탑인 Istiod가 그 역할을 수행한다.

  1. 인증서 발급 요청 (CSR): 사이드카(Envoy)가 처음 실행될 때, Istiod에게 “나 서비스 A인데, 내가 사용할 인증서 좀 줘!”라고 요청한다.
  2. 신원 확인: Istiod는 해당 파드가 정말 서비스 A가 맞는지 쿠버네티스 API를 통해 확인한다.
  3. 인증서 배달: 확인이 완료되면 Istiod는 해당 사이드카에게만 유효한 짧은 수명의 인증서를 안전하게 전달한다.

이때 인증서 안에는 SPIFFE ID라는 표준 형식이 담기며, 이것이 서비스 메시 안에서의 ‘신분증’ 역할을 한다.

mTLS: 서로의 신분증을 확인하는 양방향 검증 (Zero Trust)

일반적인 HTTPS(TLS)는 클라이언트가 서버만 확인하지만, mTLS(Mutual TLS)는 ‘양방향’이다.

  • Client Envoy: “내 신분증 여기 있어. 너도 신분증 보여줘.”
  • Server Envoy: “나도 신분증 있어. 자, 여기. 너도 내가 믿는 Istiod가 발급해준 게 맞네!”

두 사이드카가 서로의 인증서를 대조하고, 둘 다 동일한 뿌리(Root CA)에서 발급된 것임을 확인하는 순간 암호화된 터널이 뚫린다.

왜 mTLS가 강력한가?

  1. 중간자 공격(MITM) 방지: 트래픽을 가로채도 암호화되어 읽을 수 없다.
  2. 신원 도용 방지: 인증서가 없는 가짜 서비스는 메시 안에서 통신 자체가 불가능하다.
  3. 자동 갱신: 개발자가 신경 쓰지 않아도 Istiod가 주기적으로 인증서를 갈아치우기 때문에 보안 수준이 항상 높게 유지된다.

Conclusion

결국 서비스 메시에서의 보안은 “누구도 믿지 않는다(Zero Trust)”는 원칙에서 시작한다.

모든 서비스는 매번 통신할 때마다 자신의 신원을 증명해야 하며, 이 복잡한 과정을 개발자 대신 사이드카와 Istiod가 처리해 준다. 우리는 그저 안전하게 구축된 신뢰의 도로 위를 달리기만 하면 된다.