{
  "test_id": "T02",
  "verdict": "pass",
  "observed": "재실행 지침에 따라 목적지를 in-cluster mock 대신 실제 외부 호스트로 교체했다. 처음엔 예시로 제시된 httpbin.org로 시도했으나, 클러스터에 이미 존재하는 mesh-test 네임스페이스의 ServiceEntry(httpbin-ext, exportTo 미설정 → 기본값 '*'로 mesh 전역 노출)와 DestinationRule(httpbin-ext-outlier, mesh-wide), VirtualService(egress-httpbin, gateway 'mesh'에 바인딩되어 모든 사이드카의 아웃바운드에 적용)가 httpbin.org를 이미 레지스트리에 등록·정책 적용해두고 있어, REGISTRY_ONLY를 적용하기도 전인 baseline(ALLOW_ANY) 단계에서부터 HTTPS 호출이 curl exit 35(SSL connect error)로 실패했다 — 즉 httpbin.org도 이 클러스터에서는 '미등록 목적지' 대역으로 부적합함을 실행 중 발견했다(edition.cnn.com도 동일하게 exportTo 미설정으로 mesh 전역 등록되어 있어 마찬가지로 부적합). kubectl get serviceentry,virtualservice,destinationrule -A로 클러스터 전체를 조회해 어떤 Istio 리소스도 전혀 참조하지 않음을 확인한 실제 외부 호스트 postman-echo.com으로 교체해 재실행했다. 결과: baseline(ALLOW_ANY)에서 allow_any_http=200, allow_any_https=200. 네임스페이스 스코프 Sidecar로 outboundTrafficPolicy.mode: REGISTRY_ONLY를 적용하자 client 사이드카의 cluster 덤프에 BlackHoleCluster가 나타났고, registry_only_http=502(L7 vhost 미매치로 BlackHole 라우트 폴백), registry_only_https_code=000 / curl_exit=35(TLS 핸드셰이크 단계에서 연결 종료)로 두 프로토콜의 차단 신호가 명확히 달랐다. istioctl proxy-config listener 덤프(포트 443, virtualOutbound)에서 디폴트 필터체인 이름이 정확히 'virtualOutbound-blackhole'로 확인되어, HTTP는 L7 라우트 매치 실패로, HTTPS/TCP는 디폴트 필터체인 자체가 blackhole로 배선된 메커니즘으로, 서로 다른 경로를 통해 동일하게 BlackHoleCluster에 도달함이 직접 확인됐다. postman-ext-se ServiceEntry(hosts: postman-echo.com) 등록 후에는 after_se_registered_http=200, after_se_registered_https=200으로 모두 복구됐다. pass_criteria의 모든 조항(baseline 200, BlackHoleCluster 출현, HTTP 502 vs TLS 000/curl_exit!=0의 프로토콜별 차단 신호 차이, SE 등록 후 복구)이 confound 없이 정확히 재현되어 PASS. 다만 이번에도 mesh-wide(meshConfig 전역) REGISTRY_ONLY가 아닌 namespace-scope Sidecar 등가 치환을 사용했으므로, 'mesh 전체에 영향을 준다'는 blast-radius 자체는 이 테스트로 검증되지 않는다(설계상 의도된 제약, run 1과 동일).",
  "claims": [
    {
      "doc": "gw__guide-egress-gateway-https",
      "cid": "C11",
      "empirical": "supports-claim",
      "note": "REGISTRY_ONLY 적용 직후 istioctl proxy-config cluster 덤프(CMD6)에 BlackHoleCluster가 실제로 나타남을 확인."
    },
    {
      "doc": "gw__guide-egress-gateway-https",
      "cid": "C12",
      "empirical": "supports-claim",
      "note": "run 1에서는 mock 서비스가 이미 registry에 있어 TLS가 200으로 통과해 이 claim이 반박됐으나, 진짜 미등록 외부 호스트(postman-echo.com)로 재현하니 HTTP=502, TLS=000/curl_exit=35로 프로토콜별 차단 신호가 명확히 다르게 나타나 claim이 지지됨."
    },
    {
      "doc": "gw__note-egress-identity-without-mtls",
      "cid": "C4",
      "empirical": "supports-claim",
      "note": "run 1에서는 mock(이미 등록된 k8s Service)을 대상으로 해 HTTPS가 통과하며 반박됐으나, 진짜 미등록 외부 호스트로 교체하자 HTTPS(TLS)도 BlackHole되어(curl_exit=35) '등록 안 된 외부 목적지는 BlackHole로 차단된다'는 claim이 TLS 트래픽에도 성립함이 확인됨."
    },
    {
      "doc": "gw__note-sidecar-scope",
      "cid": "C6",
      "empirical": "supports-claim",
      "note": "이 claim은 '보통(HTTP의 경우) 502'로 헤지되어 있고, 실측한 HTTP 응답이 정확히 502였으므로 지지됨."
    },
    {
      "doc": "gw__src-sidecar-scope",
      "cid": "C7",
      "empirical": "supports-claim",
      "note": "HTTP 전용 claim(BlackHoleCluster로 라우팅되어 502 반환)과 정확히 일치하는 registry_only_http=502를 관찰."
    },
    {
      "doc": "gw__src-sidecar-scope",
      "cid": "C8",
      "empirical": "supports-claim",
      "note": "run 1에서는 TLS 트래픽 자체가 blackhole되지 않아 inconclusive였으나, 이번엔 진짜 미등록 외부 호스트라 TLS 연결이 curl_exit=35(SSL handshake 단계에서 연결 종료)로 실패했고, istioctl proxy-config listener 덤프에서 포트 443 virtualOutbound의 디폴트 필터체인이 'virtualOutbound-blackhole'임을 직접 확인해 TCP 연결이 blackhole 필터체인에 의해 끊긴다는 메커니즘이 지지됨. 다만 패킷 레벨(RST vs FIN)까지 캡처해 구분하지는 않았음."
    },
    {
      "doc": "gw__src-egress-gateway",
      "cid": "C1",
      "empirical": "supports-claim",
      "note": "REGISTRY_ONLY 적용 전 기본 ALLOW_ANY 상태에서 allow_any_http/https 모두 200으로, egress gateway 없이도 조용히 통과함을 확인 — '강제되지 않는다'는 claim과 일치."
    },
    {
      "doc": "arch__runbook-helm-reinstall",
      "cid": "C11",
      "empirical": "supports-claim",
      "note": "네임스페이스 스코프 Sidecar로 등가 치환한 REGISTRY_ONLY가 baseline 200 -> 적용 후 HTTP 502/TLS 000 -> SE 등록 후 200으로 정확히 재현되어, meshConfig 필드의 시맨틱(등록 안 된 목적지 차단) 자체는 지지됨. mesh-wide 전파 범위(blast radius)는 이 테스트로 검증되지 않음(설계상 의도된 제약)."
    },
    {
      "doc": "gw__report-2026-06-07_ingress-egress",
      "cid": "C11",
      "empirical": "inconclusive",
      "note": "이 claim의 핵심은 'outboundTrafficPolicy는 mesh 전역 설정이라 메시 전체에 영향을 준다'는 blast-radius 자체이며, 본 테스트는 의도적으로 namespace-scope Sidecar로 치환해 mesh 전역 변경을 하지 않았으므로 이 claim(범위 속성)은 이 테스트로 판정 불가."
    },
    {
      "doc": "xds__src-cr-xds-model",
      "cid": "C12",
      "empirical": "supports-claim",
      "note": "ServiceEntry 부재 시 HTTP/HTTPS 모두 BlackHole되고(502 / 000·curl_exit=35), ServiceEntry 등록 후 둘 다 다시 200으로 복구되는 흐름이 정확히 관찰되어 '미등록+REGISTRY_ONLY=BlackHole, 등록하면 복구'라는 메커니즘 claim이 프로토콜 양쪽 모두에서 지지됨(run 1보다 강화된 근거)."
    }
  ]
}