Gateway TLS modes check

PASSTHROUGH 서버로 붙은 클라이언트가 받은 인증서의 주체가 O=backend 였다. 이것이 말해 주는 것은?

• 게이트웨이는 TLS 를 끝내지 않고 바이트를 그대로 넘겼고, 핸드셰이크 상대는 백엔드였다
• 게이트웨이가 TLS 를 끝낸 뒤 백엔드 인증서로 다시 암호화해 클라이언트에게 돌려줬다
• credentialName 이 가리키는 Secret 에 백엔드 인증서가 잘못 들어 있었다
• tls_inspector 가 게이트웨이 인증서를 백엔드 인증서로 바꿔 끼워 내보냈다

tls.mode: SIMPLE 인 HTTPS 서버는 게이트웨이 Envoy 리스너에서 무엇이 되는가?

• tls_inspector 와 server_names 매치, 그리고 tcp_proxy
• 체인의 transport_socket 에 DownstreamTlsContext(서버 인증서), 그 뒤에 HTTP 연결 관리자
• require_client_certificate 가 켜진 DownstreamTlsContext 와 validation_context
• 클러스터 쪽의 UpstreamTlsContext 하나

PASSTHROUGH 게이트웨이에 https://<게이트웨이 IP>/ 로 붙자 연결이 곧바로 끊겼다. 가장 그럴듯한 설명은?

• IP 로 붙으면 게이트웨이가 백엔드 인증서를 검증할 수 없어 거절한다
• VirtualService 가 없어서 게이트웨이가 404 를 돌려주었다
• IP 로 붙으면 SNI 가 실리지 않아 server_names 에 맞는 체인이 없고, no_filter_chain_match 가 오른다
• tcp_proxy 는 IPv4 주소로 들어온 연결을 받지 않는다

평문 80 서버에 tls.httpsRedirect: true 를 주었다. 게이트웨이 Envoy 에서 이것은 무엇이 되는가?

• 80 리스너에 DownstreamTlsContext 가 붙어 평문 요청을 거절한다
• 라우트마다 redirect 동작이 붙어 업스트림 응답 뒤에 301 을 돌려준다
• 443 리스너로 가는 tcp_proxy 가 80 리스너에 추가된다
• http.80 라우트 설정의 virtual host 에 require_tls: ALL 이 들어가 라우트를 보기 전에 301 로 https 를 가리킨다

MUTUAL 과 OPTIONAL_MUTUAL 이 게이트웨이 Envoy 설정에서 다른 점은?

• OPTIONAL_MUTUAL 은 TLS 를 끝내지 않고 PASSTHROUGH 처럼 SNI 만 보고 백엔드로 넘긴다
• OPTIONAL_MUTUAL 은 require_client_certificate 를 끄고 validation_context 만 둔다
• OPTIONAL_MUTUAL 은 서버 인증서 없이 클라이언트 인증서만으로 핸드셰이크를 끝낸다
• MUTUAL 은 메시 인증서만 받고, OPTIONAL_MUTUAL 은 외부 CA 가 발급한 인증서만 받는다

멀티 클러스터의 east-west 게이트웨이가 AUTO_PASSTHROUGH 를 쓰는 이유로 가장 알맞은 것은?

• 게이트웨이가 TLS 를 끝내야 원격 클러스터의 인가 정책을 적용할 수 있어서
• 클라이언트 인증서 없이도 원격 서비스에 붙게 하려고
• SNI 에 목적지 클러스터 이름이 담겨 와서 VirtualService 없이 그 이름으로 곧바로 보낼 수 있어서
• SNI 를 보내지 않는 사이드카도 받아 주려고