{
  "test_id": "T74",
  "verdict": "pass",
  "observed": "echo Pod의 serviceAccountName은 default였고, pilot-agent request GET certs와 envoy admin config_dump(include_secrets)로 추출한 leaf 인증서를 openssl x509로 직접 확인한 결과 Subject는 공백(subject=)이었으며 X509v3 Subject Alternative Name은 critical 확장으로 URI:spiffe://cluster.local/ns/istio-vt-t74/sa/default 하나만 담고 있었다. echo의 istio-proxy 컨테이너에서 find로 디스크를 뒤져도 CA 루트 configmap과 OS 신뢰 저장소(ca-certificates 패키지) 파일만 있었고 워크로드 leaf 키/인증서 파일은 전혀 발견되지 않아 SDS가 디스크가 아닌 Envoy 메모리로만 인증서를 전달함이 확인됐다. client 쪽 outbound|443||echo...svc.cluster.local 클러스터의 tlsMode-istio transportSocketMatch에는 combinedValidationContext.defaultValidationContext.matchSubjectAltNames가 정확히 {exact: spiffe://cluster.local/ns/istio-vt-t74/sa/default} 하나만 설정돼 있어 secure naming(특정 신원만 허용, 와일드카드 아님)이 실제 적용됨을 확인했다. 다만 spec의 --fqdn echo.ISTIO_VT_NS.svc.homelab.local 조회는 null이 나왔는데, 이는 실제 클러스터 DNS 도메인(homelab.local, CoreDNS/resolv.conf로 확인)과 달리 Istio가 clusterDomain을 기본값 cluster.local로 사용해 Envoy 클러스터 이름을 echo.istio-vt-t74.svc.cluster.local로 생성했기 때문이며, 해당 FQDN으로 재조회해 위 결과를 얻었다.",
  "claims": [
    {
      "doc": "blog:security_mtls-spiffe-identity",
      "cid": "C4",
      "empirical": "supports-claim",
      "note": "leaf 인증서 Subject는 공백, SAN은 URI 타입으로 spiffe://cluster.local/ns/<ns>/sa/<sa> 하나만 담김 (pilot-agent JSON + openssl x509 이중 확인)."
    },
    {
      "doc": "blog:security_mtls-spiffe-identity",
      "cid": "C12",
      "empirical": "supports-claim",
      "note": "SDS가 워크로드 leaf 키/인증서를 디스크에 남기지 않고 Envoy 메모리로만 전달함을 find 결과로 확인 (디스크엔 CA root CM/OS trust store만 존재)."
    },
    {
      "doc": "xds__src-envoy-static-dynamic-xds-lab",
      "cid": "C10",
      "empirical": "supports-claim",
      "note": "client Envoy의 echo용 outbound cluster TLS validation_context(matchSubjectAltNames)가 echo의 정확한 SPIFFE ID 하나만 exact match로 허용 (secure naming). FQDN은 clusterDomain 불일치로 svc.cluster.local 사용 필요했음(환경 특이사항, 별도 claim 판정에는 영향 없음)."
    }
  ]
}