---
title: Egress HTTPS 패턴 지도 — 용어 정립과 4패턴 선택 가이드
date: 2026-07-05
type: ref
domain: istio
tags: [egress, mtls, passthrough, origination, pattern-map]
---


> [!abstract]
> egress gateway로 외부 HTTPS를 내보내는 방식은 이 아카이브에서 **4개 패턴**으로 수렴한다.
> 이 문서는 그 4패턴의 **용어를 한 곳에서 정립**하고(문서마다 별칭이 달랐다), 결정 트리·CRD 시그니처
> 비교표·패턴별 정본 문서 지도를 제공하는 **허브**다. 각 패턴의 해부·구성·실측은 전부 기존 검증
> 문서에 있으므로, 이 문서에서 새로 배우는 것은 "무엇을 어떤 이름으로 부르고, 어느 문서를 열 것인가"다.

**대상 환경:** Istio **1.30.0**, sidecar mesh (모든 링크 문서 공통)
**검증:** 이 문서는 자체 실측 없이 기존 검증 문서를 종합하는 허브다. 본문이 인용하는 T07·T90·T91·T54는 모두 교차 참조(타 번들 실측)이며, 대응 관계는 문서 끝 "검증 기록" 표에 요약돼 있다.

---

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

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

| 정식 용어 | 별칭 (같은 것) | 홉 1 (sidecar→gw) | 홉 2 (gw→외부) | 한 줄 정의 |
|---|---|---|---|---|
| **TLS Passthrough** | HTTPS passthrough, SNI passthrough | 앱 TLS 그대로 (추가 래핑 없음) | 앱 TLS 그대로 | gateway는 SNI만 보고 통과 — 가장 단순 |
| **mTLS Passthrough** | HTTPS over mTLS, ISTIO_MUTUAL passthrough | 앱 TLS + **outer `ISTIO_MUTUAL`** | 앱 TLS 그대로 (raw TCP relay) | outer만 종단해 SPIFFE 신원 확인, inner는 통과 |
| **TLS Origination** | SIMPLE origination | 평문 HTTP (+`ISTIO_MUTUAL` 권장) | gateway가 **`SIMPLE`** TLS 시작 | 앱은 평문, 암호화는 gateway 몫 |
| **이중 mTLS** | mTLS origination, double mTLS | 평문 HTTP + `ISTIO_MUTUAL` | gateway가 **`MUTUAL`**(client cert) 시작 | 두 홉이 각각 독립 mTLS |

용어 규칙 두 가지:

- **계열(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 해부](/docs/istio/egress/https-over-mtls/) §1의 교집합 논리).
- Q2의 "신원"은 IP/namespace가 아니라 **mesh CA가 보증하는 SPIFFE**다. 그 신원 위에 AuthorizationPolicy 인가까지 얹어야 비용이 정당화된다([신원 통제 가이드](/docs/istio/security/egress-mtls-identity-control/)). NetworkPolicy 수준 근사로 충분하면 ①+Calico가 더 싸다([mTLS 없이 신원 통제](/docs/istio/egress/identity-without-mtls/)).
- Q3의 이중 mTLS는 "파트너 요구 client cert를 **gateway 한 곳에서 중앙 관리**"가 본질이다. 앱이 직접 client cert를 관리해도 된다면 ②로도 파트너 mTLS를 충족할 수 있다(inner TLS가 앱↔파트너 mTLS가 되는 것 — 단 cert가 앱마다 분산된다).

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

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

| 리소스 | ① TLS Passthrough | ② mTLS Passthrough | ③ TLS Origination | ④ 이중 mTLS |
|---|---|---|---|---|
| 앱 호출 | `https://` | `https://` | `http://` | `http://` |
| SE port protocol | `TLS` | `TLS` | `HTTP`(앱측) + `TLS`(외부측) | `HTTP`(앱측) + `TLS`(외부측) |
| Gateway server | `TLS` / `PASSTHROUGH` | `TLS` / **`ISTIO_MUTUAL`** | `HTTPS` / `ISTIO_MUTUAL` | `HTTPS` / `ISTIO_MUTUAL` |
| VS leg-1 / leg-2 | `tls` / `tls` (SNI 생존) | `tls` / **`tcp`** (SNI 소비) | `http` / `http` | `http` / `http` |
| DR-hop1 `tls` | 없음 (subset만) | `ISTIO_MUTUAL` + `sni` | `ISTIO_MUTUAL` + `sni` | `ISTIO_MUTUAL` + `sni` |
| DR-hop2 `tls` | 없음 | **없음 (raw TCP)** | `SIMPLE` (+CA) | `MUTUAL` + `credentialName` |
| gateway가 보는 것 | L4 (SNI만) | L4 + **호출자 SPIFFE** | L7 + SPIFFE | L7 + SPIFFE |
| e2e 암호화 | 보존 | 보존 | gateway에서 평문 | gateway에서 평문 |
| 외부 서버 검증 주체 | 앱 | 앱 | gateway (CA) | gateway (`ca.crt`+SAN) |
| 외부 client cert | 앱이 관리 (필요 시) | 앱이 관리 (필요 시) | — | **gateway 중앙 관리** |
| L7 egress 정책/지표 | 불가 (`istio_tcp_*`) | 불가 (`istio_tcp_*`) | 가능 | 가능 |

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

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

**① TLS Passthrough**

- 구성·검증 정본: [Egress gateway HTTPS 가이드](/docs/istio/egress/gateway-https/) — Helm 설치부터 경유 증명·REGISTRY_ONLY·우회 함정까지 완결
- 신원을 mTLS 없이 근사: [TLS Passthrough + Calico NetworkPolicy](/docs/istio/egress/identity-without-mtls/)

**② mTLS Passthrough**

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

**③ TLS Origination**

- 전용 정본 없음 — 메커니즘은 [이중 mTLS 가이드](/docs/istio/egress/double-mtls-gateway-connection/)에서 `MUTUAL`을 `SIMPLE`(+CA)로 바꾼 것과 동일 골격. HTTP/HTTPS 처리 차이는 [HTTP vs HTTPS](/docs/istio/egress/http-vs-https/), 원형은 ↗ [공식 TLS Origination task](https://istio.io/latest/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/)

**④ 이중 mTLS**

- 구성 정본: [이중 mTLS — 홉마다 DR 한 벌](/docs/istio/egress/double-mtls-gateway-connection/) — credentialName SDS 제약·portLevelSettings 함정·튜닝 표 (T90)

**계열 무관 공통**

- 개념 입문: [Egress Gateway 정본](/docs/istio/egress/gateway/) · [4-CRD 멘탈모델](/docs/istio/egress/crd-mental-model/)
- DR 일반론(host 매칭·병합·검증 3단): [DestinationRule 만들기](/docs/istio/egress/destinationrule-fundamentals/)
- 커넥션 튜닝 도출식: [Egress TCP 처방전](/docs/istio/egress/tcp-tuning/) · [tcpKeepalive 필드 노트](/docs/istio/egress/tcp-keepalive-fields/)

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

1. **완료 = 200이 아니라 경유 증명.** 홉 1 매칭이 깨지면 `ALLOW_ANY`에선 sidecar가 조용히 직접 나가고 호출은 200이다. gateway access log + `REGISTRY_ONLY`까지가 완료 조건 (T90 함정 3, [TLS Passthrough 가이드](/docs/istio/egress/gateway-https/) §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:

| 주장 | 근거 |
|---|---|
| ② leg-2는 `tcp` 필수 (tls면 listener 누락) | T07 — [mTLS Passthrough 해부 §검증 기록](/docs/istio/egress/https-over-mtls/) |
| ② DR-hop2는 tls 블록 부재 = raw TCP, pool 발효 위치 | T91 — [mTLS Passthrough DR·connectionPool §검증 기록](/docs/istio/egress/mtls-passthrough-connectionpool/) |
| ④ 배선·credentialName SDS 제약·pool 발효 위치 | T90 — [이중 mTLS §검증 기록](/docs/istio/egress/double-mtls-gateway-connection/) |
| 함정: ALLOW_ANY 조용한 우회, DR 병합 최고참 승 | T90 G4 · T54 — [DR 정본 §06](/docs/istio/egress/destinationrule-fundamentals/) |

## 참조

- ↗ [Istio: Egress Gateways (TLS Passthrough)](https://istio.io/latest/docs/tasks/traffic-management/egress/egress-gateway/) — ① 공식 task
- ↗ [Istio: Egress Gateways with TLS Origination](https://istio.io/latest/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/) — ③④ 공식 task
- ↗ [Istio: Understanding TLS Configuration](https://istio.io/latest/docs/ops/configuration/traffic-management/tls-configuration/) — 모드 의미론