PeerAuthentication and identity check

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

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

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

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

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

• spiffe://cluster.local/ns/default/sa/orders
• orders.default.svc.cluster.local
• default/orders
• cluster.local/ns/default/sa/orders

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

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

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

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

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

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