PeerAuthentication 과 신원 확인

6道题. 完成作答后会显示正确答案和解析。

1. `reviews` 에 STRICT PeerAuthentication 을 걸었다. istiod 가 이것으로 바꾸는 Envoy 설정은 어디에 있는가?

   1. reviews 를 부르는 모든 사이드카의 outbound 클러스터에 TLS 설정이 생긴다
   2. reviews 사이드카의 inbound 리스너에서 평문 체인이 빠지고 클라이언트 인증서를 요구하는 TLS 체인만 남는다
   3. istiod 의 인증서 발급 설정이 바뀌어 reviews 에만 새 인증서를 준다
   4. 인그레스 게이트웨이의 리스너에 reviews 전용 SNI 체인이 더해진다

2. PERMISSIVE 모드의 inbound 리스너에서 평문과 mTLS 를 가르는 것은?

   1. tls_inspector 가 첫 바이트로 TLS 여부를 표시하고, TLS 체인과 매치 없는 평문 체인 중 하나가 골라진다
   2. HTTP 필터인 RBAC 가 요청 헤더를 보고 평문 요청을 다른 라우트로 보낸다
   3. iptables 가 평문은 15001 로, TLS 는 15006 으로 나눠 보낸다
   4. Envoy 가 두 리스너를 같은 포트에 띄워 먼저 응답한 쪽이 연결을 가져간다

3. 신뢰 도메인 `cluster.local`, 네임스페이스 `default`, 서비스 계정 `orders` 인 워크로드를 AuthorizationPolicy 의 `source.principals` 에 적는 값은?

   1. spiffe://cluster.local/ns/default/sa/orders
   2. orders.default.svc.cluster.local
   3. default/orders
   4. cluster.local/ns/default/sa/orders

4. PeerAuthentication 이 하나도 없을 때 Istio 의 기본 동작이 PERMISSIVE 인 이유로 가장 알맞은 것은?

   1. mTLS 는 성능 비용이 커서 필요한 곳에만 켜도록 권장하기 때문이다
   2. istiod 가 인증서를 발급하기 전까지는 mTLS 를 쓸 수 없기 때문이다
   3. 사이드카가 차례로 주입되는 동안 아직 사이드카가 없는 파드의 평문 호출도 받아야 하기 때문이다
   4. 쿠버네티스의 헬스 체크가 TLS 를 지원하지 않기 때문이다

5. Service `reviews` 가 `port: 80 → targetPort: 10096` 이다. 10096 만 평문으로 남기려고 portLevelMtls 에 적는 번호와 그 이유는?

   1. 10096 — iptables 가 원래 목적지 포트를 보존해 inbound 체인이 컨테이너 포트로 매치하기 때문이다
   2. 80 — 호출하는 쪽이 Service 포트로 부르므로 그 번호가 정책의 기준이다
   3. 15006 — 모든 inbound 연결이 그 포트로 꺾여 들어오기 때문이다
   4. 아무 번호나 — portLevelMtls 는 selector 가 없으면 모든 포트에 적용되기 때문이다

6. Istio 에서 인증서 SAN 대조(secure naming)가 주로 쓰이는 곳과, 받는 쪽에서 '누가 부를 수 있는가' 를 정하는 것의 짝으로 맞는 것은?

   1. 받는 쪽이 SAN 을 대조하고, 부르는 쪽은 PeerAuthentication 으로 상대를 고른다
   2. istiod 가 SAN 을 대조하고, 받는 쪽은 NetworkPolicy 로 호출자를 고른다
   3. 양쪽 모두 SAN 을 대조하지 않고 CA 서명만 본다
   4. 부르는 쪽이 서버 SAN 을 기대한 계정과 대조하고, 받는 쪽은 AuthorizationPolicy 의 principals 로 호출자를 고른다