Egress HTTPS 패턴 지도 — 용어 정립과 4패턴 선택 가이드

대상 환경: Istio 1.30.0, sidecar mesh (모든 링크 문서 공통)

1. 용어 정립 — 이 아카이브의 정식 명칭 4개

같은 패턴이 문서·커뮤니티마다 다른 이름으로 불려 혼선이 있었다(예: “HTTPS over mTLS” vs “mTLS Passthrough”). 이 표가 정본이며, 이후 모든 문서는 정식 용어 열의 이름을 쓴다.

용어 규칙 두 가지:

• 계열(family)로 먼저 가른다: 홉 2에서 gateway가 TLS를 새로 만드는가? 안 만들면 passthrough 계열(①②), 만들면 origination 계열(③④). 계열이 같으면 CRD 골격이 같고, 다르면 VS 라우트 타입부터 다르다(§3).
• “HTTPS over passthrough” 같은 조합 표현은 지양 — passthrough 자체가 “앱의 HTTPS를 그대로 통과"라는 뜻이라 동어반복이다. ①은 TLS Passthrough, ②는 mTLS Passthrough로 부른다.

2. 결정 트리 — 질문 세 개로 패턴이 정해진다

Q1. gateway가 앱 payload를 복호화해도 되는가?
 |
 +-- 안 됨 (end-to-end 암호화 유지) ---------> passthrough 계열
 |     |
 |     Q2. egress에서 호출 워크로드 신원(SPIFFE)이 필요한가?
 |     +-- 아니오 --> (1) TLS Passthrough
 |     +-- 예 ----> (2) mTLS Passthrough
 |
 +-- 됨 (gw가 L7 정책/감사, cert 중앙 관리) --> origination 계열
       |
       Q3. 외부 서버가 client cert를 요구하는가?
       +-- 아니오 --> (3) TLS Origination
       +-- 예 ----> (4) 이중 mTLS

• Q1이 갈림길의 90%다. payload를 절대 못 보게 해야 하면(PCI/PII, cert-pinning) origination 계열은 탈락이고, per-URL egress 정책·L7 감사가 목표면 passthrough 계열은 그걸 줄 수 없다(mTLS Passthrough 해부 §1의 교집합 논리).
• Q2의 “신원"은 IP/namespace가 아니라 mesh CA가 보증하는 SPIFFE다. 그 신원 위에 AuthorizationPolicy 인가까지 얹어야 비용이 정당화된다(신원 통제 가이드). NetworkPolicy 수준 근사로 충분하면 ①+Calico가 더 싸다(mTLS 없이 신원 통제).
• Q3의 이중 mTLS는 “파트너 요구 client cert를 gateway 한 곳에서 중앙 관리“가 본질이다. 앱이 직접 client cert를 관리해도 된다면 ②로도 파트너 mTLS를 충족할 수 있다(inner TLS가 앱↔파트너 mTLS가 되는 것 — 단 cert가 앱마다 분산된다).

3. CRD 시그니처 비교표 — 패턴을 리소스에서 역추적하기

운영 중 클러스터에서 “이거 무슨 패턴이지"를 판별할 때, 그리고 구성 시 오배선을 피할 때 쓰는 표다. 한 칸이라도 다른 패턴 것을 섞으면 조용히 깨진다 — 특히 VS 라우트 타입과 Gateway protocol.

표의 근거는 전부 실측이다: ②의 leg-2가 tcp여야 하는 이유(outer 종단 시 SNI 소비 → tls 라우트는 filter chain 0개로 listener 누락)는 T07, ②의 DR-hop2가 “tls 블록 부재"인 것과 connectionPool 발효 위치는 T91, ④의 배선·SDS 제약은 T90 (§검증 기록).

4. 문서 지도 — 패턴별로 어느 문서를 열 것인가

① TLS Passthrough

• 구성·검증 정본: Egress gateway HTTPS 가이드 — Helm 설치부터 경유 증명·REGISTRY_ONLY·우회 함정까지 완결
• 신원을 mTLS 없이 근사: TLS Passthrough + Calico NetworkPolicy

② mTLS Passthrough

• 패턴 해부 정본: mTLS Passthrough 해부 — 이중 봉투 데이터 경로·CRD 4종 델타·장단점·활용
• 홉별 DR·connectionPool 구성: mTLS Passthrough DR·connectionPool — 홉 2 “일반 TCP"의 올바른 DR 표현 포함 (T91)
• 실측 리포트: 이중 암호화(outer mTLS + inner TLS) 실측 — SNI 소비
• 채택 의사결정 사례: 도입 가이드 — TLS Passthrough vs mTLS Passthrough
• 신원 위 인가: Egress 신원 기반 통제

③ TLS Origination

• 전용 정본 없음 — 메커니즘은 이중 mTLS 가이드에서 MUTUAL을 SIMPLE(+CA)로 바꾼 것과 동일 골격. HTTP/HTTPS 처리 차이는 HTTP vs HTTPS, 원형은 ↗ 공식 TLS Origination task

④ 이중 mTLS

• 구성 정본: 이중 mTLS — 홉마다 DR 한 벌 — credentialName SDS 제약·portLevelSettings 함정·튜닝 표 (T90)

계열 무관 공통

• 개념 입문: Egress Gateway 정본 · 4-CRD 멘탈모델
• DR 일반론(host 매칭·병합·검증 3단): DestinationRule 만들기
• 커넥션 튜닝 도출식: Egress TCP 처방전 · tcpKeepalive 필드 노트

5. 계열 공통 원칙 — 어느 패턴이든 성립하는 것 4개

1. 완료 = 200이 아니라 경유 증명. 홉 1 매칭이 깨지면 ALLOW_ANY에선 sidecar가 조용히 직접 나가고 호출은 200이다. gateway access log + REGISTRY_ONLY까지가 완료 조건 (T90 함정 3, TLS Passthrough 가이드 §7).
2. DR은 홉마다 한 벌, host가 다르다. 홉 1 DR host = gateway Service의 레지스트리 FQDN, 홉 2 DR host = ServiceEntry 외부 host. 같은 host에 DR이 겹치면 조용한 병합(최고참 승)으로 한쪽이 무시된다 (T54).
3. connectionPool은 “그 홉의 연결을 여는 프록시"에서 발효된다. 홉 1 값 = 호출자 sidecar의 cluster(pod당 상한), 홉 2 값 = gateway의 cluster(전사 합류 상한). origination 계열(T90)과 passthrough 계열(T91) 양쪽에서 교차 실측된 원칙이다.
4. SNI 정렬 지도부터 만든다. DR sni == Gateway hosts[] == VS 매칭 호스트 — 같은 문자열이 3~6곳에 흩어지고, 한 글자 어긋나면 에러 없이 깨진다.

핵심 정리

• 용어 4개로 통일: TLS Passthrough / mTLS Passthrough / TLS Origination / 이중 mTLS. 갈림길은 “gateway가 홉 2 TLS를 만드는가”(계열) → “신원 필요한가”(passthrough 내) / “client cert 요구인가”(origination 내).
• CRD 시그니처로 패턴을 역추적할 수 있다 — Gateway protocol(TLS vs HTTPS)·VS 라우트 타입(tls/tcp vs http)·DR-hop2 tls(없음/SIMPLE/MUTUAL)가 지문이다.
• passthrough 계열의 대가는 L7 사각, origination 계열의 대가는 e2e 암호화 포기 — 둘 다 가질 수는 없다.
• 패턴 무관 공통 4원칙: 경유 증명 / host당 DR 1벌 / pool은 여는 프록시에서 발효 / SNI 정렬.

검증 기록

이 문서는 신규 실측 없이 기존 검증 문서를 종합한 허브다. 표·주장별 근거 T-run:

참조

• ↗ Istio: Egress Gateways (TLS Passthrough) — ① 공식 task
• ↗ Istio: Egress Gateways with TLS Origination — ③④ 공식 task
• ↗ Istio: Understanding TLS Configuration — 모드 의미론