{
  "test_id": "T11",
  "verdict": "pass",
  "observed": "run 1의 환경 혼동(istiod 레지스트리는 cluster.local, 클러스터 DNS는 homelab.local)을 교정해 재실행함. curl은 SHORT name(http://echo.<ns>/, http://tcp-target.<ns>:9090/)으로, AuthorizationPolicy principal은 그대로 cluster.local/ns/<ns>/sa/default(SPIFFE trustDomain은 clusterDomain과 무관)로 구성. istioctl proxy-config route로 echo 서비스의 VirtualHost domains를 직접 확인한 결과 [echo.istio-vt-t11-r2.svc.cluster.local, echo.istio-vt-t11-r2.svc.cluster.local., echo, echo.istio-vt-t11-r2.svc, echo.istio-vt-t11-r2, <clusterIP>]로, SHORT name(echo.istio-vt-t11-r2)이 정확히 이 목록에 포함됨을 확인 - 즉 Host 헤더가 실제로 vhost에 매칭되어 L7 라우팅/RBAC 평가 경로를 정상적으로 탄다. 이 상태에서 동일 신원(cluster.local/ns/istio-vt-t11-r2/sa/default)에 대한 DENY AuthorizationPolicy를 echo(named http 포트)와 tcp-target(unnamed 포트, raw TCP)에 각각 적용한 결과: (1) L7(echo) - curl이 l7_deny=403을 반환했고, echo istio-proxy 접속 로그에 'GET / HTTP/1.1\" 403 - rbac_access_denied_matched_policy[ns[istio-vt-t11-r2]-policy[deny-client-on-echo]-rule[0]]'가 정확히 남아 response_code=403, response_flags='-'(비특이), response_code_details에 rbac_access_denied류 사유가 기록됨을 확인. (2) L4(tcp-target) - curl이 l4_deny_code=000, l4_deny_exit=52(Empty reply from server, connection reset 성격)를 반환했고, tcp-target istio-proxy 로그에 '\"- - -\" 0 - - rbac_access_denied_matched_policy[ns[istio-vt-t11-r2]-policy[deny-client-on-tcp-target]-rule[0]]'가 남아 response_code=0(HTTP 상태줄 자체가 없음), response_flags='-', response_code_details에 동일하게 rbac_access_denied류 사유가 기록됨을 확인. pass_criteria의 두 조건(L7=403+rbac 사유, L4=000/미기록+비정상 종료) 모두 충족되어 PASS 판정.",
  "claims": [
    {
      "doc": "gw__guide-egress-adoption-passthrough-vs-mtls",
      "cid": "C8",
      "empirical": "supports-claim",
      "note": "동일 신원 기반 DENY가 L7(HTTP, named port)에서는 403 응답으로, L4(raw TCP, unnamed port)에서는 HTTP 상태 코드 없는 connection reset(curl 000/exit 52)으로 서로 다르게 나타남을 vhost 매칭이 정상 성립하는 환경에서 재확인 - L7/L4 프로토콜 계층에 따라 신원 기반 제어의 관측 형태가 근본적으로 다르다는 주장을 뒷받침."
    },
    {
      "doc": "blog:security_egress-mtls-identity-control",
      "cid": "C7",
      "empirical": "supports-claim",
      "note": "run 1에서는 clusterDomain 불일치로 Host 헤더가 vhost에 매칭되지 않아 RBAC 평가 자체가 스킵되고 200이 나왔으나, SHORT name으로 vhost 매칭을 정상화한 이번 재실행에서는 동일 신원 기반 DENY가 HTTP에서 기대대로 403(rbac_access_denied_matched_policy 사유 포함)으로 나타남을 확인 - '신원 기반 제어가 HTTP에서 403으로 강제된다'는 주장이 성립함. (run 1의 반박은 환경 혼동에 의한 아티팩트였음이 확인됨)"
    },
    {
      "doc": "xds__src-envoy-response-flags",
      "cid": "C15",
      "empirical": "supports-claim",
      "note": "L7(echo, response_code=403)과 L4(tcp-target, response_code=0) 두 경우 모두에서 response_flags 필드는 '-'(비특이)로 남고, 실제 거부 사유는 response_code_details(rbac_access_denied_matched_policy[...])에만 기록됨을 재확인 - response_flags가 RBAC 거부를 구분해 표시하지 않는다는 문서 취지와 일치하며, 이번에는 L7 경로에서도 동일 패턴이 정상적으로 관측되어 근거가 보강됨."
    }
  ]
}