..

내부 443 통신 요구사항

Overview

최근 인프라 보안 강화의 일환으로 “내부 애플리케이션 간 통신 시에도 80(HTTP)이 아닌 443(HTTPS) 통신을 수행하라”는 신규 요구사항이 발생했다. 이에 따라 엔지니어팀에서 테스트 환경의 HTTPS 구성과 툴체인 설정을 마친 상태이고, 이제 중요한 것은 외부로부터의 인바운드 암호화를 넘어, 클러스터 내부망(Pod-to-Pod) 통신을 어떻게 안전하게 보호했는지 개발자 관점에서 상세히 파악해야한다. 이번 연재를 통해 Istio Service Mesh가 이 요구사항을 어떻게 스마트하게 해결했는지 그 과정을 기록한다.

요구사항 (Requirements)

현장에서 도출된 핵심 미션과 기술적 목표

  • 내부 통신 보안: xxx-app ↔ xxx-oss 등 내부 서비스 간 호출 시 443 포트 기반의 암호화(mTLS) 적용.
  • 개발자 관점의 이해: 인프라에서 설정된 mTLS가 실제 앱 통신에 어떤 영향을 주는지, 소스 코드 수정 없이 어떻게 443 통신이 완성되는지 분석.
  • 검증 체계 구축: 엔지니어팀이 구성한 툴체인을 활용하여 실제 암호화 여부를 확인하고 장애 지점을 파악.

연재 계획

  1. [#23] 개요: 내부 443 통신 요구사항, 왜 ‘앱’이 아닌 ‘Mesh’인가? (기존 방식 vs Mesh)
  2. [#24] 구조: Sidecar(Envoy)는 어떻게 내 트래픽을 가로채는가? (Transparent Proxy의 원리)
  3. [#25] 동작: Magic of Mesh - 앱은 80으로 던지고, 네트워크는 443으로 흐르는 원리
  4. [#26] 보안: Deep Dive - mTLS 핸드셰이크와 신뢰 구축의 기술적 상세
  5. [#27] 인증: Istiod CA 기반의 인증서 라이프사이클 (발급부터 자동 갱신까지)
  6. [#28] 분석: 실전 트래픽 여정 분석 - HAProxy부터 내부 서비스(xxx-oss)까지
  7. [#29] 검증: 운영자의 눈 - Kiali와 로그로 mTLS 통신을 증명하고 장애 대응하기

약속 (Our Principle)

  • 추상화: 보안은 인프라 영역으로 밀어내고, 앱 개발자는 비즈니스 로직에만 집중
  • 명확성: 설정으로만 존재하는 보안이 아니라, 관측 도구로 증명 가능한 보안을 지향
  • 학습: 엔지니어팀의 결과물을 단순히 수용하지 않고, 동작 원리를 상세히 이해하여 운영 역량을 내재화

Next Step

다음 글에서는 [#23] 개요: 내부 443 통신 요구사항, 왜 ‘앱’이 아닌 ‘Mesh’인가? (기존 방식 vs Mesh)를 다룰 예정. 기존 방식처럼 모든 마이크로서비스에 직접 SSL/TLS 설정을 관리할 때 발생하는 운영 리스크와, 이를 해결하는 Mesh의 핵심 가치를 비교한다.