{
  "test_id": "T58",
  "verdict": "pass",
  "observed": "run 1의 FQDN/서비스 레지스트리 불일치(echo.<ns>.svc.homelab.local 사용 시 PassthroughCluster로 새어나가 STRICT mTLS가 평문 연결을 거부)를 harness-notes.md의 교정 규칙에 따라 curl 대상을 단축명(http://echo.<ns>/)으로 바꿔 해결했다. 새 네임스페이스 istio-vt-t58-r2에서 client(2/2)·echo(2/2)를 기동한 뒤 istioctl proxy-config routes로 echo의 vhost 도메인에 단축명이 정확히 등록됨을 사전 확인했다. 이후 6개 관측 전부 pass_criteria와 일치했다: (1) PeerAuthentication STRICT만 걸었을 때 identity가 다른 client 요청은 200으로 통과 (2) 엉뚱한 principal만 매칭하는 ALLOW AuthorizationPolicy를 추가하자 403으로 차단(deny-by-default 발동) (3) RequestAuthentication만 추가했을 때 토큰 없는 요청은 200으로 여전히 통과(단독으로는 게이트하지 않음) (4) 형식이 잘못된 토큰은 401로 거부 (5) requestPrincipals:['*']를 요구하는 AuthorizationPolicy를 추가하자 토큰 없는 요청은 403으로 바뀜(RequestAuthentication이 채운 속성을 AuthorizationPolicy가 실제로 게이트) (6) 유효한 JWT를 실었을 때는 200. 측정 과정에서 istiod가 여러 동시 테스트 네임스페이스(istio-vt-t17/38/47-r2 등)로 xDS 설정을 밀어내느라 propagation 지연이 있어 일부 중간 관측(after_wrong_principal_allow, reqauth_only_no_token/bad_token, authz_requires_jwt_no_token)이 최초 1회 각각 200/403/403/200(기대와 다름)로 나왔으나, istioctl proxy-config listener로 실제 Envoy에 로드된 RBAC/JWT 필터 설정을 직접 대조 확인하고 재측정하여 모두 pass_criteria와 일치하는 값으로 안정화됨을 검증했다(환경적 구조 결함이 아니라 config propagation lag였음 — run.sh의 sleep을 5s에서 10s로 늘려 재현성 확보).",
  "claims": [
    {
      "doc": "sec__note-security-resource-trio",
      "cid": "C1",
      "empirical": "supports-claim",
      "note": "PeerAuthentication STRICT를 echo에 단독 적용한 상태에서 identity가 다른(대상 서비스 계정이 아닌) client의 요청이 200으로 정상 통과함을 관측했다(peerauth_strict_only=200). 이어서 엉뚱한 principal만 매칭하는 ALLOW AuthorizationPolicy를 추가하자 client의 실제 identity가 어떤 규칙과도 매칭되지 않아 deny-by-default가 발동해 403으로 바뀜을 관측했다(after_wrong_principal_allow=403). 즉 PeerAuthentication은 mTLS/identity 속성만 채울 뿐 그 자체로는 차단하지 않으며, 실제 게이트는 AuthorizationPolicy(가 하나라도 존재하는 순간의 deny-by-default 포함)라는 클레임을 직접 지지한다."
    },
    {
      "doc": "sec__note-security-resource-trio",
      "cid": "C5",
      "empirical": "supports-claim",
      "note": "RequestAuthentication만 echo에 적용한 상태에서 토큰 없는 요청은 200으로 통과(reqauth_only_no_token=200, RequestAuthentication 단독으로는 게이트하지 않음)하고, 형식이 잘못된/서명 불일치 토큰은 401로 거부됨(reqauth_only_bad_token=401, 검증 실패는 RequestAuthentication 자체가 401 처리)을 확인했다. 이어서 requestPrincipals:['*']를 요구하는 AuthorizationPolicy(ALLOW)를 추가하자 토큰 없는 요청은 403으로 바뀌고(authz_requires_jwt_no_token=403, jwt_authn이 채운 payload.iss/sub 메타데이터가 없어 RBAC 매칭 실패 -> deny-by-default), 유효한 JWT를 실은 요청은 200으로 통과(authz_requires_jwt_valid_token=200)함을 확인했다. RequestAuthentication은 인증 속성만 채우고, AuthorizationPolicy가 추가되어야만 실제 게이트가 작동한다는 클레임을 6가지 상태 전이 전부에서 직접 지지한다."
    }
  ]
}