Injection and Interception Check

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

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

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

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

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

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

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

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

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

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

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

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