주입과 가로채기 확인

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

1. `istio-init` 의 인자 `-p 15001 -z 15006` 에서 두 번호의 역할로 맞는 것은?

   1. 15001 은 들어오는 연결, 15006 은 나가는 연결을 꺾어 넣는 포트다
   2. 15001 은 Envoy 관리 포트, 15006 은 프록시 헬스체크 포트다
   3. 15001 은 앱이 밖으로 보내는 연결, 15006 은 밖에서 들어오는 연결을 꺾어 넣는 포트다
   4. 두 포트 모두 들어오는 연결용이고 프로토콜(HTTP/TCP)에 따라 나뉜다

2. `istio-init` 의 `-u 1337` 과 `istio-proxy` 의 `runAsUser: 1337` 이 같아야 하는 이유는?

   1. UID 1337 이 보낸 패킷을 가로채지 않아야 프록시의 요청이 다시 프록시로 꺾이는 고리가 생기지 않는다
   2. 두 컨테이너가 같은 UID 여야 공유 볼륨의 인증서 파일을 함께 읽을 수 있다
   3. istiod 가 UID 로 프록시를 식별하므로 다르면 xDS 연결이 거절된다
   4. 1337 은 리눅스에서 NET_ADMIN 을 가진 예약 사용자라 규칙을 고칠 수 있다

3. `istio-init` 에만 NET_ADMIN·NET_RAW 를 주고 `istio-proxy` 는 모든 권한을 버리는 설계의 이유는?

   1. 프록시가 NET_ADMIN 을 가지면 Envoy 가 성능 최적화를 끄기 때문이다
   2. 초기화 컨테이너는 root 가 아니면 이미지를 받을 수 없기 때문이다
   3. 쿠버네티스가 같은 파드의 두 컨테이너에 같은 권한을 주는 것을 금지하기 때문이다
   4. 규칙은 한 번만 심으면 되므로, 오래 사는 프록시가 뚫려도 파드 네트워크를 바꿀 수 없게 권한을 떼어 둔다

4. `-d 15090,15021,15020` 으로 세 포트를 들어오는 쪽 가로채기에서 빼는 이유로 가장 적절한 것은?

   1. 세 포트는 TLS 를 쓰므로 iptables 가 해석할 수 없다
   2. kubelet 헬스체크와 프로메테우스 긁기가 Envoy 라우팅을 거치지 않고 프록시에 직접 닿게 하려고
   3. 세 포트가 1024 보다 커서 REDIRECT 대상이 될 수 없다
   4. 앱 컨테이너가 같은 번호를 쓰면 충돌하므로 미리 비워 둔다

5. 메시 설정이 `REGISTRY_ONLY` 인데 앱이 메시가 모르는 외부 호스트를 부르면 무슨 일이 일어나는가?

   1. PassthroughCluster 로 가서 원래 목적지로 그대로 나간다
   2. istiod 가 DNS 를 조회해 ServiceEntry 를 자동으로 만든다
   3. BlackHoleCluster 로 가서 사이드카가 503 을 돌려준다
   4. iptables 가 연결을 거절해 앱이 connection refused 를 받는다

6. Envoy 의 들어오는 쪽 클러스터 이름이 `inbound|8080||` 처럼 가운데가 비어 있는 이유는?

   1. 들어오는 쪽에는 서브셋이 없어서 서브셋 칸과 호스트 칸이 비어 있다
   2. istiod 가 아직 엔드포인트를 모를 때 임시로 쓰는 이름이다
   3. 평문 트래픽용 클러스터라 TLS 정보가 들어갈 칸이 비었다
   4. 포트 이름을 지정하지 않은 서비스라서 이름 칸이 비었다