mesh series: envoy protocol upgrade(packet boxing unboxing)
Overview
지난 포스팅에서 iptables가 어떻게 트래픽을 가로채 Envoy(Sidecar)에게 배달하는지 살펴봤다.
가로채기(Intercept)가 성공했다면, 이제 Envoy는 이 패킷을 가공할 차례다.
앱 로그에는 분명 http://...:80으로 찍히는데, 실제 네트워크 장비에서는 왜 443(TLS) 패킷만 보이는 걸까?
이번 포스트에서는 Plain HTTP가 mTLS 암호화 통신으로 둔갑하는 ‘프로토콜 업그레이드’ 과정을 다룬다.
패킷의 여정: Step-by-Step
1. 출항 (App A inside Pod)
앱 컨테이너는 평소처럼 HTTP/1.1 80 패킷을 생성한다.
- Source:
App A - Protocol:
HTTP (Plain Text) - Payload:
"Hello, Service B!"
2. 검문소 진입 (Sidecar A)
iptables에 의해 가로채진 패킷이 Sidecar A(Envoy)에 도착한다.
Envoy는 이 패킷을 분석하고 다음과 같이 변환한다.
- Protocol Upgrade: HTTP 요청을 mTLS(Mutual TLS) 터널 안으로 집어넣는다. (Encapsulation)
- Identity 추가: 자신이
Istiod로부터 발급받은 인증서를 패킷에 실어 ‘나 믿을만한 놈이야’라고 증명한다.
3. 망해(Network) 진출
이제 Pod 밖으로 나가는 패킷은 더 이상 80이 아니다.
- Protocol: HTTPS (TLS v1.3)
- Destination Port: 15008 (Istio mTLS 기본 포트) 또는 443
- 이때 외부에서
tcpdump로 패킷을 가로채면, 내용은 암호화되어 있어 절대 읽을 수 없다.
수신측의 반전: Sidecar B의 역할
패킷이 목적지인 Service B의 Pod에 도착하면 반대의 마법이 일어난다.
- Inbound 가로채기: Sidecar B가 들어오는 443(mTLS) 패킷을 가로챈다.
- 복호화 (Downgrade): 자신의 인증서로 상대방(Sidecar A)을 검증하고, 암호화된 옷을 벗겨낸다.
- 배달: 원래의 HTTP/1.1 80 상태로 복구된 패킷을 내부 앱 컨테이너(
localhost)로 던져준다.
왜 ‘프로토콜 업그레이드’인가?
이 매커니즘의 핵심은 “앱은 요청의 시작과 끝에서 오직 80만 본다”는 점이다.
- App A (Client): “난 80으로 보냈어.”
- App B (Server): “난 80으로 받았어.”
- 네트워크 (Network): “내 구간에서는 오직 강력한 암호화(443/mTLS)만 흘렀어.”
이것이 바로 개발자가 코드를 고치지 않고도 보안 요구사항을 완벽히 충족할 수 있는 이유, 즉 인프라에 의한 프로토콜 업그레이드다.
Conclusion
결국 서비스 메시 환경에서 통신 보안이란, 양쪽 끝단(App)을 속이지 않으면서 중간 통로(Network)만 안전한 터널로 교체하는 정교한 작업이다. 우리는 이 과정을 통해 보안 강화와 개발 생산성이라는 두 마리 토끼를 모두 잡을 수 있었다.
Next
다음 포스트에서는 mTLS 동작 원리와 내부 신뢰 구축 과정을 설명한다.
단순히 암호화만 하는 것이 아니라,
서로가 서로를 어떻게 믿고 통신을 허락하는지 그 ‘신뢰(Trust)’의 기술적 메커니즘을 다룬다.