게이트웨이 TLS 모드 확인

6문항. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

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

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

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

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

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

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

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

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

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

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

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

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