[Istio] 암호화된 트래픽을 열어보지도 않고 라우팅하는 비결: SNI와 PASSTHROUGH 모드 🔒🚦

안녕하세요! 오늘은 Istio를 다루면서 마주치게 되는 조금 특별한 라우팅 방식에 대해 이야기해보려 합니다.

보통 인그레스 게이트웨이(Gateway)라고 하면, 밖에서 들어온 HTTPS 암호를 풀고(Terminating), 내용을 확인한 뒤 내부 서비스로 보내주는 역할을 주로 하죠.

 

그런데 말입니다...🤔 게이트웨이가 "나는 암호 안 풀래! 그냥 그대로 토스할 거야!"라고 선언하면(PASSTHROUGH), 게이트웨이는 패킷 안에 있는 URL 경로나 헤더를 전혀 볼 수가 없습니다.

 

내용을 못 보는데 어떻게 목적지 서비스(booking-service)를 알고 찾아가는 걸까요? 여기서 등장하는 주인공이 바로 SNI입니다.

 

---

1. SNI (Server Name Indication)가 뭐길래? 📨

SNI는 Server Name Indication의 약자로, 쉽게 비유하자면 "암호화된 금고(패킷) 겉면에 붙어 있는 '수신자 이름표' 포스트잇"입니다.

💡 왜 생겨났나요?

HTTPS 통신은 보안을 위해 데이터를 암호화합니다. 과거에는 암호화 연결(TLS Handshake)이 성립되기 전에는 서버가 "클라이언트가 어떤 도메인에 접속하고 싶은지" 알 방법이 없었습니다. 하나의 서버 IP에 여러 도메인(예: [의심스러운 링크 삭제됨], b.com)이 연결되어 있을 때 문제가 되었죠.

그래서 "암호화 통신을 시작하기 위한 인사(Client Hello) 단계에서, 접속하려는 도메인 주소(Hostname)를 평문으로 살짝 알려주자!"라고 약속한 기술이 바로 SNI입니다.

---

2. 코드 뜯어보기: PASSTHROUGH와 SNI의 콜라보 🤝

보여주신 YAML 코드는 Istio가 이 SNI 정보를 어떻게 활용하는지 아주 잘 보여주는 예시입니다. 하나씩 뜯어볼까요?

1️⃣ Gateway 설정: "난 내용은 안 볼 거야 (패스스루)"

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: booking-gateway
spec:
  servers:
  - port:
      number: 443
      protocol: HTTPS
    hosts:
    - booking.example.com
    tls:
      mode: PASSTHROUGH  # 👈 여기가 핵심!

• mode: PASSTHROUGH: 게이트웨이에게 "TLS 암호화를 여기서 풀지 마(Do not terminate)"라고 지시합니다.
• 게이트웨이는 암호화된 데이터를 그대로 통과시키므로, HTTP 헤더나 URL Path(/login, /pay 등)를 전혀 읽을 수 없습니다.

2️⃣ VirtualService 설정: "겉면에 적힌 이름(SNI)을 보고 배달해!"

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
  hosts:
  - booking.example.com
  tls:                # 👈 http가 아니라 tls 규칙을 사용합니다!
  - match:
    - port: 443
      sniHosts:       # 👈 암호화된 패킷 겉면의 이름표 확인
      - booking.example.com
    route:
    - destination:
        host: booking-service
        port:
          number: 443

• tls: HTTP 내용을 볼 수 없으니 http 라우팅 규칙 대신 tls (TCP 레벨) 라우팅 규칙을 씁니다.
• sniHosts: 게이트웨이는 내용을 못 보는 대신, TLS 핸드셰이크 시 클라이언트가 보낸 SNI 필드(booking.example.com)를 확인합니다.
• "내용은 모르겠지만, 겉에 booking이라고 써있으니 booking-service로 보내주자!"라고 판단하는 것이죠.

---

3. 전체 동작 흐름 요약 🚀

이 설정이 적용되었을 때 트래픽은 다음과 같이 여행합니다.

1. Client (브라우저) 💻: https://booking.example.com에 접속 시도. 이때 "나 booking에 접속할 거야"라고 SNI에 적어서 보냄.
2. Istio Gateway 🛡️: 트래픽 도착! PASSTHROUGH 모드라 암호를 풀지 않음. 대신 SNI를 슬쩍 확인.
3. 라우팅 결정 🔀: VirtualService를 보니 "SNI가 booking이면 booking-service로 보내라"고 되어 있음.
4. 전달 (Forwarding) 📦: 암호화된 상자 그대로 booking-service 파드로 전달.
5. Booking Service (Pod) 🔓: 최종 목적지인 파드가 직접 암호를 풀고 요청을 처리.

---

4. 언제 이 방식을 쓰나요? (Use Cases)

보통은 게이트웨이에서 암호를 풀지만, 아래의 경우에는 이 방식(SNI 라우팅)이 필수적입니다.

1. End-to-End 보안 (Zero Trust) 🔐: 게이트웨이조차 믿지 못해서, 트래픽이 파드에 도착할 때까지 절대 암호가 풀리면 안 되는 경우.
2. 서비스별 인증서 관리 📜: 게이트웨이가 아닌, 각 서비스(Pod)가 자신만의 고유한 인증서를 가지고 직접 관리해야 할 때.

---

🏁 마치며

정리하자면, SNI는 암호화된 세상에서 길을 잃지 않게 해주는 네비게이션 주소와 같습니다.

Istio에서 PASSTHROUGH를 쓴다는 것은 게이트웨이를 "단순 배달부"로 만드는 것이고, 이때 배달부가 집을 찾을 수 있게 해주는 유일한 단서가 바로 sniHosts 설정이라는 점, 꼭 기억해 주세요! 😉

도움이 되셨다면 좋아요 부탁드립니다!

---