TLS 구성 이해하기

TLS 구성 이해하기 (Understanding TLS Configuration)

Istio의 가장 중요한 기능 중 하나는 메시로 들어오고, 나가고, 메시 내부의 네트워크 트래픽을 잠그고 보호하는 능력이에요. 이 페이지에서는 Istio에서 요청을 보낼 때 관련된 다양한 연결과 그 TLS 설정을 구성하는 방법을 배워요.

출처: Istio 문서

본문

Istio의 가장 중요한 기능 중 하나는 메시로 들어오고, 나가고, 메시 내부의 네트워크 트래픽을 잠그고 보호하는 능력이에요. 하지만 TLS 설정을 구성하는 것은 혼란스러울 수 있고 잘못 구성되는 흔한 원인이에요. 이 문서는 Istio에서 요청을 보낼 때 관련된 다양한 연결과 그 연결의 TLS 설정이 어떻게 구성되는지 설명하려고 해요. 가장 흔한 TLS 구성 문제의 요약은 TLS configuration mistakes를 참고하세요.

Sidecar

Sidecar 트래픽에는 다양한 관련 연결이 있어요. 하나씩 살펴볼게요.

외부 인바운드 트래픽

sidecar가 캡처하는 외부 클라이언트에서 오는 트래픽이에요. 클라이언트가 메시 내부에 있다면 이 트래픽은 Istio 상호 TLS로 암호화될 수 있어요. 기본적으로 sidecar는 mTLS와 non-mTLS 트래픽을 모두 수용하도록 구성되는데, 이를 PERMISSIVE 모드라고 해요. 이 모드는 STRICT(트래픽이 mTLS여야 함)나 DISABLE(트래픽이 평문이어야 함)로 구성할 수도 있어요. mTLS 모드는 PeerAuthentication 리소스를 사용해 구성돼요.

로컬 인바운드 트래픽

sidecar에서 애플리케이션 서비스로 가는 트래픽이에요. 이 트래픽은 항상 그대로 전달돼요. 이것이 항상 평문이라는 뜻은 아니라는 점을 기억하세요. sidecar는 TLS 연결을 통과시킬 수 있어요. 그저 새 TLS 연결이 sidecar에서 시작되지 않는다는 뜻이에요.

로컬 아웃바운드 트래픽

sidecar가 가로채는 애플리케이션 서비스에서 나가는 트래픽이에요. 애플리케이션은 평문이나 TLS 트래픽을 보낼 수 있어요. 자동 프로토콜 선택이 활성화되어 있으면 Istio가 자동으로 프로토콜을 감지해요. 그렇지 않으면 목적지 서비스의 포트 이름을 사용해 프로토콜을 수동으로 지정해야 해요.

외부 아웃바운드 트래픽

sidecar를 떠나 외부 목적지로 가는 트래픽이에요. 트래픽은 그대로 전달되거나 TLS 연결(mTLS 또는 표준 TLS)이 시작될 수 있어요. 이는 DestinationRule 리소스의 trafficPolicy에 있는 TLS mode 설정으로 제어돼요. mode 설정이 DISABLE이면 평문을 보내고, SIMPLE, MUTUAL, ISTIO_MUTUAL은 TLS 연결을 시작해요.

핵심 요점은 다음과 같아요.

PeerAuthentication은 sidecar가 어떤 유형의 mTLS 트래픽을 수용할지를 구성하는 데 사용돼요.
DestinationRule은 sidecar가 어떤 유형의 TLS 트래픽을 보낼지를 구성하는 데 사용돼요.
포트 이름 또는 자동 프로토콜 선택은 sidecar가 트래픽을 어떤 프로토콜로 파싱할지를 결정해요.

자동 mTLS

위에서 설명했듯이 DestinationRule은 나가는 트래픽이 mTLS를 사용할지 여부를 제어해요. 하지만 모든 워크로드에 대해 이를 구성하는 것은 지루할 수 있어요. 일반적으로 가능한 모든 곳에서 Istio가 항상 mTLS를 사용하고, 메시의 일부가 아닌 워크로드(즉 sidecar가 없는 워크로드)에만 평문을 보내길 원할 거예요.

Istio는 "자동 mTLS(Auto mTLS)"라는 기능으로 이를 쉽게 만들어요. Auto mTLS는 정확히 그렇게 작동해요. DestinationRule에서 TLS 설정이 명시적으로 구성되지 않으면 sidecar가 Istio 상호 TLS를 보낼지 자동으로 결정해요. 이는 어떤 구성 없이도 모든 메시 내부 트래픽이 mTLS로 암호화된다는 뜻이에요.

게이트웨이

게이트웨이에 대한 어떤 요청에도 두 개의 연결이 있어요.

인바운드 요청: curl이나 웹 브라우저 같은 일부 클라이언트가 시작하는 요청이에요. 이것을 흔히 "다운스트림(downstream)" 연결이라고 불러요.
아웃바운드 요청: 게이트웨이가 일부 백엔드로 시작하는 요청이에요. 이것을 흔히 "업스트림(upstream)" 연결이라고 불러요.

이 두 연결 모두 독립적인 TLS 구성을 가져요.

ingress와 egress 게이트웨이의 구성은 동일하다는 점을 기억하세요. istio-ingress-gateway와 istio-egress-gateway는 단지 두 개의 특수화된 게이트웨이 배포일 뿐이에요. 차이는 ingress 게이트웨이의 클라이언트는 메시 외부에서 실행되는 반면, egress 게이트웨이의 경우 목적지가 메시 외부에 있다는 것이에요.

인바운드

인바운드 요청의 일부로 게이트웨이는 라우팅 규칙을 적용하기 위해 트래픽을 디코드해야 해요. 이는 Gateway 리소스의 server 구성에 기반해 수행돼요. 예를 들어 인바운드 연결이 평문 HTTP라면 포트 프로토콜이 HTTP로 구성돼요.

apiVersion: networking.istio.io/v1
kind: Gateway
...
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP

유사하게 원시 TCP 트래픽의 경우 프로토콜은 TCP로 설정돼요.

TLS 연결에는 몇 가지 추가 옵션이 있어요.

어떤 프로토콜이 캡슐화되어 있나요?

연결이 HTTPS라면 server 프로토콜을 HTTPS로 구성해야 해요. 그렇지 않으면 TLS로 캡슐화된 원시 TCP 연결의 경우 프로토콜을 TLS로 설정해야 해요.

TLS 연결이 종료되나요, 아니면 통과되나요?

passthrough 트래픽의 경우 TLS mode 필드를 PASSTHROUGH로 구성하세요.

apiVersion: networking.istio.io/v1
kind: Gateway
...
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: PASSTHROUGH

이 모드에서 Istio는 SNI 정보를 기반으로 라우팅하고 연결을 목적지로 그대로 전달해요.

상호 TLS를 사용해야 하나요?

상호 TLS는 TLS mode MUTUAL로 구성할 수 있어요. 이를 구성하면 클라이언트 인증서가 요청되고 구성된 caCertificates 또는 credentialName에 대해 검증돼요.

apiVersion: networking.istio.io/v1
kind: Gateway
...
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: MUTUAL
      caCertificates: ...

아웃바운드

인바운드 측이 기대하는 트래픽 유형과 처리 방법을 구성하는 반면, 아웃바운드 구성은 게이트웨이가 보낼 트래픽 유형을 제어해요. 이는 sidecar의 외부 아웃바운드 트래픽과 마찬가지로, DestinationRule의 TLS 설정 또는 기본적으로 자동 mTLS에 의해 구성돼요.

유일한 차이는 이를 구성할 때 Gateway 설정을 주의 깊게 고려해야 한다는 거예요. 예를 들어 Gateway가 TLS PASSTHROUGH로 구성되고 DestinationRule이 TLS originination을 구성하면 이중 암호화(double encryption)가 되고 말 거예요. 이것은 작동하지만 종종 바람직한 동작은 아니에요.

게이트웨이에 바인딩된 VirtualService도 Gateway 정의와 일관성을 보장하기 위해 주의가 필요해요.

더 알아보기 (Learn more)

Istio 트래픽 관리 구성 섹션