Outbound 집약 설계서
Istio Egress Gateway로 Squid 경로 일원화

요약과 결정사항

바꾸는 것은 경로이지, 프록시가 아닙니다. GW존의 Squid는 그대로 유지되고 (API·도메인별 egress 허용 정책도 계속 Squid 운영팀 관할), 앱도 지금처럼 HTTP_PROXY/HTTPS_PROXY로 Squid를 향해 요청을 보냅니다. 달라지는 것은 그 요청이 지나가는 길입니다. 각 워커노드에서 곧장 GW존으로 가던 트래픽이, 앞으로는 sidecar에 가로채여 전용 egress 노드의 egress gateway를 경유한 뒤에만 Squid에 도달합니다. 전환이 끝나면 워커노드 → GW존 방화벽 ACL을 제거하는 것이 이 프로젝트의 완료 조건입니다.

배경 — forward proxy와 HTTP_PROXY

1.1 왜 Squid를 쓰는가

프록시(proxy)는 "대신 연결해 주는 중계 서버"입니다. 그중 forward proxy는 내부에서 인터넷으로 나가는 방향을 담당하며, Squid는 이 역할의 대표적인 소프트웨어입니다.

쓰는 이유는 밖으로 나가는 문을 하나로 모으기 위해서입니다. 파드 수천 개가 제각각 인터넷에 나가면 누가 어디로 나갔는지 알 수도, 막을 수도 없습니다. 그래서 방화벽으로 "프록시 말고는 아무도 밖으로 못 나감"(default-deny)을 만들고, 유일하게 열린 문인 Squid에서 허용·차단·기록을 한 곳에 모읍니다.

1.2 HTTP_PROXY 환경변수의 정체

이 변수는 운영체제 기능이 아닙니다. 커널과 소켓 API에는 프록시라는 개념 자체가 없습니다. Deployment의 env:에서 kubelet과 runc를 거쳐 프로세스 메모리에 놓인 평범한 문자열이고, 이를 읽고 행동을 바꾸는 유일한 주체는 앱이 사용하는 HTTP 클라이언트 라이브러리 (curl/libcurl, Python requests, Go net/http 등)입니다. 요청을 만들기 직전에 읽는 "관례"입니다.

변수가 설정되면 앱의 네트워크 동작이 정확히 세 가지 바뀝니다:

"관례"라는 말은 안 지키는 프로그램이 많다는 뜻이기도 합니다. 운영에서 가장 자주 터지는 지점입니다:

1.3 어디에 적는가 — 등록소는 없다

자연스러운 다음 질문: "그래서 Squid 주소는 시스템 어디에 등록하나?" 답은 등록소가 존재하지 않는다입니다. DNS의 /etc/resolv.conf 같은 중앙 설정 파일이 없습니다. 환경변수는 프로세스가 execve()로 태어나는 순간 부모로부터 복사되는 문자열 목록(environ)이고, 이후 시스템 어디에도 "이 프로세스의 프록시는 X"라는 기록이 남지 않습니다. 따라서 "어디에 적는가"의 정답은 그 프로세스의 environ이 조립되는 지점이며, 프로세스가 태어나는 경로마다 지점이 다릅니다:

일반 리눅스에서의 등록과 효과 — 실측

가장 원초적인 형태부터 봅니다. 셸에서의 등록은 두 가지이고, 등록 전후의 차이는 curl이 어디로 연결을 시도하는지로 즉시 관찰됩니다:

# 방법 1 — 셸 세션에 등록: 이후의 모든 자식 프로세스가 environ 을 상속
export HTTPS_PROXY=http://squid.test:3128
curl -sk https://api.demo.test/

# 방법 2 — 그 명령 하나에만 부여 (해당 프로세스의 environ 에만 추가)
HTTPS_PROXY=http://squid.test:3128 curl -sk https://api.demo.test/

# 효과 실측 (동반 문서의 재현 랩: squid.test=프록시, api.demo.test=origin)
등록 전:   *   Trying 192.0.2.2:443      ← 목적지로 직접 시도
등록 후:   *   Trying 127.0.0.1:3128     ← 프록시로. 목적지 이름은 CONNECT 문자열이 됨

쿠버네티스에서의 표준형

실무 표준은 네임스페이스에 프록시 ConfigMap 하나를 두고 각 Deployment가 참조하는 형태입니다:

apiVersion: v1
kind: ConfigMap
metadata:
  name: proxy-env
data:
  HTTPS_PROXY: "http://squid.gw-zone.example:3128"
  HTTP_PROXY:  "http://squid.gw-zone.example:3128"
  NO_PROXY:    "localhost,127.0.0.1,.svc,.cluster.local,<serviceCIDR>,<apiserver IP>"
---
# Deployment 쪽
spec:
  template:
    spec:
      containers:
      - name: app
        envFrom:
        - configMapRef:
            name: proxy-env

1.4 두 변수, 두 요청 형태 — 스킴이 갈림길이다

이름 때문에 흔히 생기는 오해를 여기서 정리합니다. HTTP_PROXY와 HTTPS_PROXY는 "프록시에게 어떻게 말할지"를 정하는 변수가 아닙니다. 대상 URL의 스킴에 따라 어느 프록시 주소를 쓸지 고르는 주소록일 뿐이며(보통 둘 다 같은 Squid 주소), 프록시 소켓에 무엇을 보낼지는 변수명이 아니라 대상 URL의 스킴이 결정합니다.

CONNECT 자체는 GET·POST와 같은 급의 표준 HTTP/1.1 메서드입니다. 평문 요청 라인과 헤더를 보내면 프록시는 상태 라인이 있는 정상 HTTP 응답을 돌려줍니다 — 허용이면 200 Connection established, 정책 거부면 403, 프록시 인증이 필요하면 407. 특수한 점은 두 가지뿐입니다:

• request-target의 형태 — URL이 아니라 host:port만 쓰는 authority-form입니다. HTTP 요청 라인의 대상 표기는 아래 세 형태가 전부이며, 이 문서의 흐름과 정확히 대응합니다.
• 2xx 응답의 효과 — 응답이 오는 순간 그 TCP 커넥션은 HTTP이기를 멈춥니다. 이후로는 요청/응답 프레이밍이 적용되지 않는 원시 바이트 릴레이가 되고, 그래서 그 안으로 TLS든 HTTP/2든 gRPC든 자유롭게 흐릅니다. HTTP 요청 하나가 커넥션의 성격을 바꾸는 셈입니다.

1.5 NO_PROXY — 독립 스위치가 아니라 예외 목록

NO_PROXY의 정확한 지위부터 잡아야 합니다. 라이브러리는 요청을 만들 때마다 아래 결정을 돌고, NO_PROXY는 그 2단계에서만 읽히는 예외 목록입니다:

그림에서 두 가지가 바로 따라 나옵니다. 첫째, 프록시 변수가 없으면 NO_PROXY는 아예 관여할 기회가 없습니다 — "프록시를 타지 않게 하는" 주 스위치는 NO_PROXY가 아니라 프록시 변수의 부재(또는 제거) 자체이고, NO_PROXY는 프록시 세계 안에서 일부 목적지만 빼내는 조각칼입니다. 둘째, 결정의 결과 "직접 연결"은 성공이 아니라 시도입니다 — 도달 여부는 방화벽이 정합니다.

네 조합 실측

env -i로 환경을 비운 뒤 조합별로 curl의 결정(Trying 대상)만 관찰한 결과입니다:

① 변수 없음                         *  Trying 192.0.2.2:443     ← 직접 시도
② HTTPS_PROXY만                     *  Trying 127.0.0.1:3128    ← 프록시로
③ HTTPS_PROXY + NO_PROXY(매치)      *  Trying 192.0.2.2:443     ← 예외로 직접
④ NO_PROXY만 (프록시 변수 없음)     *  Trying 192.0.2.2:443     ← ①과 완전히 동일

①과 ④가 완전히 동일하다는 것이 핵심 실증입니다. 운영 증상으로 번역하면 — "NO_PROXY에 넣었더니 외부 API가 timeout" = 직접 시도가 방화벽에 막힌 정상 동작이고, "프록시 변수를 지웠는데 일부 파드는 여전히 됨" = 목적지가 내부이거나 노드 ACL이 아직 남아 있다는 뜻입니다.

매칭 문법 자체도 함정입니다. 비교는 요청 URL의 호스트 문자열 기준이고 비교 전에 DNS를 하지 않으므로, NO_PROXY=10.0.0.0/8은 https://internal-api.corp.example처럼 이름으로 쓴 URL에는 절대 매치되지 않습니다 (그 이름이 10.x로 해석되더라도). CIDR 매칭은 URL 호스트가 IP 리터럴일 때만 동작하며(Go, requests), 문법 표준이 없어 런타임마다 다릅니다.

K8s 실전 세트는 대략 다음과 같습니다:

NO_PROXY=localhost,127.0.0.1,.svc,.cluster.local,<serviceCIDR>,<podCIDR>,<apiserver IP>

요청 흐름 해부 — CONNECT의 실제

이 파트가 문서 전체의 기술적 토대입니다. "프록시를 지나간다"는 말이 바이트 수준에서 무엇을 뜻하는지 알아야, 뒤에서 나올 "gateway는 최종 목적지를 모른다"거나 "SNI만 평문"이라는 설계 근거가 이해됩니다.

2.1 기준선 — 프록시가 없을 때

앱이 https://api.example.com/api/ping을 직접 호출하면 네 가지 일을 전부 앱이 합니다: ① 이름 해석(DNS) ② TCP 연결 ③ TLS 핸드셰이크(인증서 검증 포함) ④ 요청 전송.

2.2 HTTPS_PROXY가 설정됐을 때 — CONNECT 터널

같은 URL인데 앱의 행동이 완전히 바뀝니다. 흐름은 두 국면으로 나뉩니다. 앞부분은 프록시가 전부 읽을 수 있는 평문 국면, 뒷부분은 프록시가 의미를 모르는 바이트만 나르는 암호화 국면입니다.

3번 단계에서 앱이 프록시 소켓에 쓰는 실제 바이트, 그리고 200 응답 직후의 바이트는 이렇습니다 (실측 캡처 기준):

== 대상이 https:// 일 때 — 앱 → 프록시 첫 바이트 ==
CONNECT api.example.com:443 HTTP/1.1
Host: api.example.com:443
User-Agent: curl/8.5.0
Proxy-Connection: Keep-Alive        ← URL의 경로·쿼리(/v1/pay?user=123)는 어디에도 없음

== 대상이 평문 http:// 일 때 — 완전히 다른 모드 ==
GET http://api.example.com/v1/pay?user=123 HTTP/1.1   ← 전체 URL이 그대로 노출(absolute-form)
Host: api.example.com

== "200 Connection established" 직후 앱이 보내는 바이트 ==
16 03 01 02 00 ...                  ← 0x16 0x03 0x01 = TLS 핸드셰이크 레코드의 시작
평문으로 읽히는 문자열은 api.example.com(SNI), http/1.1(ALPN) 뿐 — 나머지는 암호 협상 데이터

즉 CONNECT는 "이 host:port로 가는 통로를 뚫어달라"는 요청이지 HTTP 요청의 전달이 아닙니다. 통로가 열리면 TLS 세션은 앱과 origin 사이에 end-to-end로 성립하고, 인증서 검증도 앱이 origin의 인증서를 상대로 직접 수행합니다. 터널이 순수 TCP이므로 내부 프로토콜은 자유입니다 — 프록시 구간이 HTTP/1.1이어도 터널 안에서는 HTTP/2, gRPC, websocket이 그대로 흐릅니다.

2.3 프록시는 무엇을 보고, 무엇을 근거로 판단하는가

따라서 HTTPS에 대한 허용/차단 판단의 근거는 출발지 IP + CONNECT의 host:port (+ 인증)이 전부입니다. 검증 강도를 높이는 사다리가 존재합니다:

클라이언트 쪽에서 bump의 존재를 탐지하는 방법은 발급자(issuer) 체인 확인입니다:

curl -v https://example.com 2>&1 | grep -E 'subject:|issuer:'
*  subject: CN=example.com
*  issuer:  O=Corp Internal CA ...   ← 공인 CA가 아닌 발급자면 경로상 어딘가가 TLS를 가로채는 중

2.4 이름 해석(DNS)은 누가 하는가

증거는 Squid access.log에 남습니다 — HIER_DIRECT/<IP> 필드가 Squid가 스스로 해석해서 연결한 IP의 기록입니다. 이 구조 덕분에 파드는 외부 도메인을 해석할 능력이 전혀 없어도 외부 API를 호출할 수 있습니다(air-gapped 환경에서 성립하는 이유). 본 설계는 Squid를 유지하므로 이 역할 배치는 전환 후에도 변하지 않습니다.

2.5 Squid 내부 처리와 로그

Squid는 요청 라인을 파싱한 뒤 http_access 규칙을 위에서 아래로 평가해 첫 매치에서 결정하고(deny → 403 HTML + X-Squid-Error 헤더), 허용이면 자체 resolver로 목적지를 해석해(실패 → 503) TCP를 연결한 뒤, CONNECT는 200 회신 후 무해석 릴레이로, 평문 HTTP는 캐시·헤더 조작을 거쳐 전달합니다. 로그는 연결이 닫힐 때 한 줄입니다:

1784177289.182  409  10.32.4.17  TCP_TUNNEL/200  4593  CONNECT example.com:443  -  HIER_DIRECT/104.20.23.154  -
└ epoch(ms)    └지속ms └클라이언트    └결과/상태      └bytes  └메서드+대상(경로 없음)       └ Squid가 해석해 연결한 IP
1784177289.192    0  10.32.4.17  TCP_DENIED/403  3374  CONNECT www.badsite.test:443  -  HIER_NONE/-   text/html

목표 아키텍처

현재는 모든 워커노드가 각자 GW존 방화벽 ACL을 통해 Squid로 나갑니다. 목표는 그 경로를 app존의 전용 egress 노드로 모으고, 전환 완료 후 워커노드별 ACL을 제거하는 것입니다.

최종 트래픽 경로는 다음과 같습니다:

app (HTTP_PROXY 유지) → sidecar가 :3128 TCP 인터셉트
  → [ISTIO_MUTUAL] → egress gateway (:7777, egress 노드 고정)
  → plain TCP → squid.gw-zone.example:3128 → internet

3.1 설계 원칙

• Squid 대체가 아니라 경로 집약 — 목적지 DNS 해석과 도메인 ACL은 계속 Squid의 일. egress gateway는 "누가 Squid에 접근하나"를 좁히는 장치.
• 역할 분리가 조직도와 일치 — 어느 도메인/API로 나가는가 = Squid 운영팀 ACL, 어느 워크로드가 이 경로를 쓰는가 = 플랫폼팀 AuthorizationPolicy.
• 무장애 최우선 — 앱 설정 무변경(A안), 기존 ACL을 살려둔 병행 구간 확보, VirtualService 삭제만으로 즉시 롤백 가능한 순서 설계.

3.2 왜 A안인가 — 체이닝 방식 비교

Istio 구성 상세

필요한 객체는 네 종류가 전부입니다. 각 객체가 어느 홉에 작용하는지부터 보면 나머지는 배선 문제입니다.

4.1 노드 준비와 gateway 배치

kubectl label node egress-01 egress-02 node-role.kubernetes.io/egress=
kubectl taint node egress-01 egress-02 dedicated=egress:NoSchedule

# IstioOperator (helm gateway chart도 동일 개념)
spec:
  components:
    egressGateways:
    - name: istio-egressgateway
      enabled: true
      namespace: istio-egress
      k8s:
        replicaCount: 2                      # egress 노드 2대에 각 1개
        nodeSelector:
          node-role.kubernetes.io/egress: ""
        tolerations:
        - key: dedicated
          value: egress
          effect: NoSchedule
        service:
          ports:
          - name: tls-squid
            port: 7777
            targetPort: 7777

4.2 ServiceEntry — Squid를 mesh에 등록

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: squid-gw
  namespace: istio-egress
spec:
  hosts: ["squid.gw-zone.example"]
  addresses:                       # GSLB VIP 집합 — 원천은 GSLB 설정 (방화벽 ACL과 동일 목록)
  - "<SQUID_VIP_1>/32"
  - "<SQUID_VIP_2>/32"
  location: MESH_EXTERNAL
  resolution: DNS
  ports:
  - number: 3128
    name: tcp-squid
    protocol: TCP
  exportTo: ["."]                  # "."은 불변 멤버 — 이유와 확대 규칙은 4.7

addresses와 resolution — 같은 이름을 쓰는 서로 다른 두 단계

이 두 필드는 모순처럼 보이지만("IP를 박는데 왜 DNS?") 각각 다른 단계를 지시합니다. sidecar(Envoy 프로세스 하나) 안에는 테이블이 두 개 있고, DNS의 답이 들어가는 곳은 그중 하나뿐입니다:

즉 이 구조에는 같은 이름을 해석하는 주체가 셋 있습니다 — 앱(요청 직전 getaddrinfo), Envoy 클러스터(발신 직전), 그리고 addresses는 해석하지 않는 인간의 선언. Squid VIP가 바뀌면 따라가는 쪽은 ②(이미 DNS)이고, ①은 사람이 바꿔야 합니다.

왜 매칭 키는 DNS로 만들 수 없는가

두 자리가 DNS에 던지는 질문의 종류가 다르기 때문입니다. 발신(②)에 필요한 답은 "지금 살아있는 주소 하나"(존재 질의 — DNS가 잘하는 것)지만, 매칭(①)에 필요한 답은 "앱이 받았을 수 있는 모든 답의 집합"(전칭 질의)인데 DNS 프로토콜에는 전칭을 묻는 쿼리가 없습니다 — 매 질의는 표본 하나일 뿐입니다. 특히 단일 로테이션 A 레코드(우리 GSLB)에서는 Envoy의 스냅샷이 어느 순간에도 1개라, 그걸 키로 쓰면 풀이 N개일 때 앱 dial의 (N−1)/N이 리스너를 비켜갑니다. 또한 istiod가 설정 시점에 해석해 키를 만들면 앱이 요청 시점에 받은 답과 어긋나는 race가 생깁니다 (다른 시각·다른 리졸버·로테이션). 그래서 Istio의 선택지는 둘뿐입니다 — 사람이 집합을 선언하거나(addresses), 모른다고 전부를 주장하거나(0.0.0.0).

판별자 사다리 — 왜 이 포트만 addresses가 필요한가

미묘한 진실 하나 — 3128 트래픽에도 이름은 있습니다(CONNECT host:443 라인). 하지만 그걸 읽으려면 protocol: HTTP를 선언해 Envoy를 프록시 대화의 해석 주체로 만들어야 하고, 그것이 정확히 B안으로 넘어가는 스위치입니다. A안의 TCP 선언은 "이름이 있어도 읽지 않기로 한" 의도적 선택이며, 그 대가가 addresses입니다. (반대로 3128을 TLS로 잘못 선언하면 — 첫 바이트 0x43이 ClientHello가 아니라 어느 체인에도 미매치 → 연결 리셋됩니다.)

addresses 부재의 세 가지 상태

GSLB 가변 A레코드 대응 — addresses를 무엇으로 채우나

우리 Squid 도메인은 GSLB 경유라 질의마다 다른 IP를 답합니다. 단 GSLB는 무한 IP 생성기가 아니라 유한한 VIP 풀에서 골라 답하는 장치이므로, 첫 행동은 설정이 아니라 확인입니다 — GSLB 팀에 풀 멤버 목록을 받으세요(원천은 GSLB 설정, dig는 검증용). 그 성격에 따라:

# 드리프트 감지 (CI/크론) — 실제 DNS 답이 addresses 집합의 부분집합인지
LIVE=$(for i in $(seq 20); do dig +short squid.gw-zone.example; done | sort -u)
for ip in $LIVE; do
  grep -q "$ip" serviceentry.yaml || { echo "DRIFT: $ip not in addresses"; exit 1; }
done

검증 — 두 테이블의 대조

istioctl proxy-config listeners <파드> --port 3128
# addresses 있음: VIP별 리스너 (198.51.100.10:3128 …) / 없음: 0.0.0.0:3128
istioctl proxy-config endpoints <파드> --cluster "outbound|3128||squid.gw-zone.example"
# 실 VIP가 보이고, 반복 실행 시 GSLB 로테이션 따라 바뀜 — 그래도 위 listeners는 불변
# = "DNS는 발신에만 유입된다"의 물증

4.3 DestinationRule — 홉 1을 mTLS로

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: egressgw-squid
  namespace: istio-egress
spec:
  host: istio-egressgateway.istio-egress.svc.cluster.local
  subsets:
  - name: squid
    trafficPolicy:
      portLevelSettings:
      - port:
          number: 7777
        tls:
          mode: ISTIO_MUTUAL
          sni: squid.gw-zone.example

4.4 Gateway — egress gateway의 수신 리스너

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: squid-egress
  namespace: istio-egress
spec:
  selector:
    istio: egressgateway
  servers:
  - port:
      number: 7777
      name: tls-squid
      protocol: TLS
    hosts: ["squid.gw-zone.example"]
    tls:
      mode: ISTIO_MUTUAL          # sidecar가 감싼 mTLS를 여기서 종료

4.5 VirtualService — 두 홉을 하나로 배선

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: squid-via-egressgw
  namespace: istio-egress
spec:
  hosts: ["squid.gw-zone.example"]
  gateways: ["mesh", "squid-egress"]
  exportTo: ["."]                  # ServiceEntry와 동일하게 단계적 확대
  tcp:
  - match:                         # 홉 1 — 모든 sidecar에서
    - gateways: ["mesh"]
      port: 3128
    route:
    - destination:
        host: istio-egressgateway.istio-egress.svc.cluster.local
        subset: squid
        port:
          number: 7777
  - match:                         # 홉 2 — gateway에서 진짜 Squid로
    - gateways: ["squid-egress"]
      port: 7777
    route:
    - destination:
        host: squid.gw-zone.example
        port:
          number: 3128

gateways: ["mesh"]가 "클러스터의 모든 sidecar에 이 라우팅을 심어라"는 뜻이고, 두 번째 블록이 gateway 쪽 배선입니다. 롤백 관점에서 이 객체가 스위치입니다 — 기존 노드 ACL이 살아있는 동안 이 VirtualService를 삭제하면 sidecar는 ServiceEntry를 통해 Squid로 직행하는 원래 경로로 즉시 복귀합니다.

4.6 층위 읽기 — Gateway의 TLS와 HTTP/1.1 프록시 대화

4.3~4.5를 겹쳐 읽으면 자연스러운 질문이 생깁니다 — "Gateway는 TLS로 받는데, 프록시 대화는 전부 평문 HTTP/1.1 아닌가?" 답은 층이 다르다입니다. Gateway의 TLS는 홉 ② (sidecar→gateway) 구간의 포장이고, 앱의 HTTP/1.1 대화는 그 포장 안의 내용물로 통과합니다. 홉별로 와이어에 실리는 것을 보면:

포트를 3128/7777로 가른 이유 — 숫자 7777 자체는 임의값이고, 설계 결정은 "두 홉의 포트를 다르게"입니다. ① 두 리스너는 계약이 다릅니다(3128=평문 프록시 대화, 7777=mTLS 화물) — 첫 바이트부터 다른 세계(0x43 vs 0x16)라, 번호를 갈라두면 오배선이 침묵 오작동이 아니라 즉시 식별 가능한 실패(reset/400)로 나타납니다. ② 두 홉의 매칭 공간이 격리되어 설정 실수의 합성 사고가 원천 차단됩니다. ③ 방화벽·Calico·AuthorizationPolicy·대시보드의 규칙이 포트만으로 홉을 지목할 수 있습니다.

오류는 대칭으로 나타납니다 — DR 설정 누락이면 sidecar가 평문 발신 → gateway가 0x43("C")을 ClientHello로 기대하다 handshake 실패 → 앱은 reset. 반대로 Gateway를 평문으로 잘못 열면 sidecar의 ClientHello가 Squid까지 흘러가 400. 부록 트러블슈팅 표의 첫 두 행이 이 메커니즘입니다.

4.7 exportTo — 파일럿 격리와 세 객체 정합

SE·VS·DR에는 각각 exportTo가 있고, 값은 세 종류입니다 — "."(객체가 사는 네임스페이스 자신), 구체 네임스페이스 이름 나열, "*"(전체, 기본값). 나열이 파일럿 단계의 도구입니다: [".", "payments", "settlement"]처럼 시작해 확대는 리스트에 추가하는 PR, 최종 단계에 "*".

세 객체의 exportTo가 어긋나면 "부분 가시성"이라는 미묘한 장애가 됩니다. 어느 하나만 안 보이는 네임스페이스에서의 증상:

따라서 운영 규칙은 하나입니다 — SE·VS·DR 세 객체의 exportTo를 항상 같은 리스트로 (kustomize overlay에서 세 객체에 동일 patch를 묶어 강제). 그리고 확대의 의미가 ACL 제거를 기점으로 바뀝니다: 제거 전엔 리스트에서 빼면 원래 경로로 안전 복귀, 제거 후엔 빼는 순간 그 네임스페이스의 외부 통신이 중단됩니다.

4.8 검증 명령

# sidecar에 3128 라우팅이 심어졌는가
istioctl proxy-config listener <앱파드> -n <ns> --port 3128

# 앱 → gateway 홉의 tlsMode가 ISTIO_MUTUAL인가
istioctl proxy-config cluster <앱파드> -n <ns> | grep egressgateway

# gateway의 7777 필터체인과 server_names(SNI) 확인
istioctl proxy-config listener deploy/istio-egressgateway -n istio-egress --port 7777

# 파일럿 파드에서 실트래픽
curl -v -x http://squid.gw-zone.example:3128 https://<허용도메인>/

# 컷오버의 결정적 신호 — Squid access.log의 클라이언트 IP가
# 워커노드 → egress 노드 IP로 바뀌는지 확인

워크로드 단위 통제 — AuthorizationPolicy

이 파트가 홉 1을 굳이 ISTIO_MUTUAL로 만든 이유입니다. 오늘의 구조에는 "누가 프록시를 쓸 수 있는가"에 대한 통제가 없습니다(노드 단위 ACL = 노드 위 모든 파드가 사용 가능). 전환과 함께 이 통제를 새로 확보합니다.

5.1 왜 mTLS가 전제인가 — 신원은 인증서에만 실린다

Istio에서 워크로드 신원은 istiod가 발급하는 X.509 인증서의 URI SAN에 SPIFFE ID로 각인됩니다. AuthorizationPolicy를 집행하는 것은 연결을 받는 쪽 Envoy의 RBAC 필터이고, 이 필터의 source.namespaces 매칭은 IP 조회가 아니라 클라이언트 인증서 문자열의 파싱입니다 — /ns/ 다음 세그먼트를 꺼내 정책과 비교합니다. 인증서가 없는 plain TCP 연결에는 추출할 원료 자체가 없고, 그때 Envoy가 아는 "누가"는 패킷의 소스 IP(= ipBlocks 필드)가 전부입니다.

IP→네임스페이스 조회로 구현하지 않은 이유도 분명합니다. Envoy는 연결마다 쿠버네티스 API를 조회하지 않는 데이터플레인이고, 파드 IP는 반납·재할당되는 위치 정보라 갱신 지연 동안 엉뚱한 워크로드가 통과하는 race가 생깁니다. IP는 위치이지 신원이 아니므로, Istio는 신원을 암호학적으로 검증 가능한 유일한 운반체인 인증서에만 묶었습니다.

5.2 정책으로 가능한 것과 불가능한 것

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: squid-clients
  namespace: istio-egress
spec:
  selector:
    matchLabels:
      istio: egressgateway
  action: ALLOW
  rules:
  - from:
    - source:
        namespaces: ["payments", "fds"]          # 또는 principals로 SA 단위
    to:
    - operation:
        ports: ["7777"]

5.3 무장애 정책 롤아웃 — 관찰 → 작성 → 적용

mTLS를 켜는 것과 정책을 거는 것은 분리할 수 있고, 분리해야 합니다. 전환 기간의 mTLS는 통제가 아니라 신원 수집 인프라입니다.

1. 전환 완료까지 정책 없이 mTLS만 운영.
2. gateway access log에 피어 신원을 찍어 실사용 인벤토리를 수집:

# istio meshConfig에 provider 추가
extensionProviders:
- name: egress-san-log
  envoyFileAccessLog:
    path: /dev/stdout
    logFormat:
      text: "[%START_TIME%] peer=%DOWNSTREAM_PEER_URI_SAN% dst=%UPSTREAM_HOST% bytes=%BYTES_SENT%/%BYTES_RECEIVED% dur=%DURATION%\n"
---
apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: egressgw-san-logging
  namespace: istio-egress
spec:
  selector:
    matchLabels:
      istio: egressgateway
  accessLogging:
  - providers:
    - name: egress-san-log

3. 관찰된 SPIFFE ID 목록으로 ALLOW 규칙을 작성해 적용하고, gateway 로그에서 거부(denied)가 0인 것을 확인한 뒤 필요하면 좁혀갑니다.

무장애 전환 절차

운영 유의사항과 함정

7.1 강제력의 완성 — Calico 이중 잠금

이 프로젝트의 보안 이득은 gateway를 세우는 날이 아니라 ACL을 제거하는 날 실현됩니다. sidecar 미주입 파드·hostNetwork 파드·노드 프로세스는 mesh 밖이므로, 방화벽 제거와 함께 클러스터 안쪽에서도 잠급니다. 전제 확인 한 줄 — 파드 트래픽이 노드 IP로 SNAT되는지:

calicoctl get ippool -o yaml | grep natOutgoing     # → true (kubespray 기본값)

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: squid-only-via-egressgw
spec:
  selector: istio != 'egressgateway'
  order: 100
  types: [Egress]
  egress:
  - action: Deny
    protocol: TCP
    destination:
      nets: ["<SQUID_VIP_1>/32", "<SQUID_VIP_2>/32"]   # SE addresses와 동일한 GSLB VIP 집합
      ports: [3128]

명시적 Deny 한 줄이라 나머지 트래픽은 기존 프로파일대로 흐릅니다. 전 클러스터 대상이므로 스테이징에서 order 충돌을 먼저 확인하세요.

7.2 타임아웃 3층

장수명 커넥션(스트리밍·websocket·gRPC)의 목을 조를 수 있는 지점이 이제 세 층입니다 — sidecar idle timeout → gateway TCP idle timeout(Envoy 기본 1시간) → Squid의 read_timeout/client_lifetime. 셋 중 최솟값이 실효값입니다. 해당 유형의 앱이 있다면 DestinationRule의 connectionPool.tcp.idleTimeout을 Squid 설정과 명시적으로 정렬하세요. 정렬하지 않으면 "가끔 끊기는데 재현 안 됨" 티켓이 생깁니다.

7.3 감사 추적의 단절 (PCI 관점)

집약 후 Squid가 보는 소스는 전부 egress 노드 IP로 뭉개집니다 — "어느 팀/파드가 어느 도메인에 갔는가"를 Squid 로그 단독으로 소급할 수 없게 됩니다. 보완은 로그 이원화입니다: gateway의 SAN 로그(Part 5.3)가 "어느 워크로드가 언제 Squid로 향했나"를, Squid access.log가 "그 시각 어느 도메인으로 나갔나"를 담당하고 시간·커넥션 기준으로 상관 분석합니다. 감사 문서의 세그먼트 경계와 추적 방법이 바뀌는 지점이므로 전환 전에 감사 요건과 대조하세요.

7.4 에러 시그니처의 변화

실패 지점이 3단이 되면서 앱이 보는 증상으로 구간을 특정할 수 있습니다:

7.5 나머지 체크리스트

• 인증서 수명 의존 — 홉1이 istiod의 발급·로테이션(기본 TTL 24h)에 묶입니다. sidecar 간 통신과 동일한 기계라 새 리스크 클래스는 아니며, istiod 가용성 알람이 있으면 충분합니다.
• 스케일 상한 = egress 노드 수 — HPA maxReplicas를 노드 수용량과 정렬하고, 새 replica가 nodeSelector를 벗어나지 않는지 확인합니다.
• Proxy-Authorization — 앱이 프록시 인증을 쓴다면 크레덴셜이 CONNECT 헤더에 평문으로 실립니다. 홉1의 ISTIO_MUTUAL이 클러스터 구간에서는 이를 감싸주며, gateway → Squid 구간은 GW존 내부 신뢰 경계에 위임됩니다.
• CONNECT 허용 = 임의 TCP 허용 — 터널 내부 프로토콜은 자유이므로, 443으로 향하는 비-TLS 트래픽까지 구분하려면 Squid 쪽 peek(SNI 검증)이 필요합니다. gateway 층에서는 원리상 불가.
• Go의 env 캐시 — HTTP_PROXY 값을 바꿔도 Go 앱은 재시작 전까지 미반영입니다. 전환 자체는 env 무변경이라 영향 없지만, 트러블슈팅 중 env를 만질 때 기억하세요.

부록 — 트러블슈팅 · 용어집

8.1 트러블슈팅 표

8.2 용어집

forward proxy

내부 → 인터넷 방향을 중계하는 프록시. 나가는 문을 하나로 모으는 장치.

CONNECT

"이 host:port로 가는 TCP 통로를 뚫어달라"는 평문 HTTP 메서드. 경로·쿼리는 실리지 않는다.

absolute-form

평문 http:// 대상일 때 프록시에 보내는 요청 형태. 요청 라인에 전체 URL이 담긴다.

SNI

TLS ClientHello에 평문으로 실리는 목적지 호스트명. 복호화 없이 읽을 수 있는 유일한 이름 신호.

splice / peek / bump

Squid의 TLS 개입 3단계 — 릴레이만 / SNI만 확인 / 완전 복호화(MITM).

HIER_DIRECT

Squid access.log 필드. Squid가 스스로 해석해 연결한 origin IP의 기록.

SPIFFE ID

spiffe://cluster.local/ns/<ns>/sa/<sa> 형식의 워크로드 신원. 인증서 URI SAN에 각인.

ISTIO_MUTUAL

Istio가 발급·관리하는 인증서로 양방향 TLS를 맺는 모드. 신원 기반 정책의 전제.

ServiceEntry

mesh 외부 목적지를 Istio 레지스트리에 등록하는 객체. addresses로 매칭 IP를 고정할 수 있다.

Gateway (Istio)

gateway 파드 Envoy의 리스너 정의. tls.mode가 해당 포트의 수신 보안을 결정한다.

VirtualService

라우팅 규칙. gateways: ["mesh"]는 모든 sidecar에 규칙을 심는다는 뜻.

AuthorizationPolicy

수신 측 Envoy RBAC 필터의 정책. TCP에서는 L4 필드(principal·namespace·port)까지만.

natOutgoing (Calico)

파드가 클러스터 밖으로 나갈 때 노드 IP로 SNAT하는 IPPool 옵션. 노드 IP 기반 ACL의 전제.

exportTo

Istio 객체의 가시 범위. 파일럿 → 전체 확대의 점진 전환 스위치로 사용.