..
mesh series: client wants zero trust series(istio service mesh)
Overview
최근 인프라 보안 강화의 일환으로 “내부 애플리케이션 간 통신 시에도 80(HTTP)이 아닌 443(HTTPS) 통신을 수행해주세요” 라는 요구사항이 발생했다.
이에 따라 엔지니어팀에서 테스트 환경의 HTTPS 구성과 툴체인 설정을 진행했다. 이제 중요한 것은 외부로부터의 인바운드 암호화를 넘어, 클러스터 내부망(Pod-to-Pod) 통신을 어떻게 안전하게 보호했는지 개발자 관점에서 상세히 파악해야한다. 이번 연재를 통해 Istio Service Mesh가 이 요구사항을 어떻게 스마트하게 해결했는지 그 과정을 기록한다.
요구사항 (Requirements)
고객사에서 도출된 핵심 미션과 기술적 목표
- 내부 통신 보안:
xxx-app ↔ xxx-oss등 내부 서비스 간 호출 시 443 포트 기반의 암호화(mTLS) 적용. - 개발자 관점의 이해: 인프라에서 설정된 mTLS가 실제 앱 통신에 어떤 영향을 주는지, 소스 코드 수정 없이 어떻게 443 통신이 완성되는지 분석.
- 검증 체계 구축: 엔지니어팀이 구성한 툴체인을 활용하여 실제 암호화 여부를 확인하고 장애 지점을 파악.
연재 계획
- [프롤로그] 왜 이 시리즈를 시작했는가: 내부 443 통신 요구사항과 Service Mesh라는 선택
현재 글 보기 - [1편] 왜 앱이 아니라 Mesh가 책임져야 하는가: 내부 HTTPS 요구사항의 해법
/why-should-use-mesh.html - [2편] Envoy는 어떻게 내 트래픽을 가로채는가: Sidecar와 Transparent Proxy의 실제 구조
/envoy-how-to-intercept.html - [3편] 앱은 80으로 보냈는데 왜 네트워크는 443으로 흐를까: Envoy의 프로토콜 업그레이드
/envoy-protocol-boxing-unboxing.html - [4편] Envoy는 상대를 어떻게 믿는가: mTLS와 Istiod 기반 신뢰 체계의 내부 동작
/mtls-mechanism-with-envoy.html
약속 (Our Principle)
- 추상화: 보안은 인프라 영역으로 밀어내고, 앱 개발자는 비즈니스 로직에만 집중을 목표로한다.
- 명확성: 설정으로만 존재하는 보안이 아니라, 관측 도구로 증명 가능한 보안을 지향한다.
- 학습: 엔지니어팀의 결과물을 단순히 수용하지 않고, 동작 원리를 상세히 이해하여 운영 역량을 내재화를 목표한다.
Next Step
다음 포스트에서는왜 앱이 아니라 Mesh가 책임져야 하는가: 내부 HTTPS 요구사항의 해법를 다룬다. 기존 방식처럼 모든 마이크로서비스에 직접 SSL/TLS 설정을 관리할 때 발생하는 운영 리스크와, 이를 해결하는 Mesh의 핵심 가치를 비교한다.