服务网格 21：认证成功为何仍会被拒绝

证明“是谁”不等于证明“能做什么”

orders 以正确工作负载证书连接库存，只说明对端代理能够验证它的工作负载身份；一名最终用户带有效 JWT，也只说明令牌在指定签发者、密钥、受众及有效期等规则下通过校验。业务是否放行，还要看作用于 inventory 的授权策略与请求属性。对等身份来自 mTLS，最终用户身份来自请求令牌；两者不能互相替代，更不能把客户端自填的 X-Request-ID 当作认证结果。

Istio 的 RequestAuthentication 有一个很容易写错的边界：携带了不合法的令牌会被拒绝；没有携带令牌的请求默认仍能进入后续处理。如果业务要求“必须提供有效 JWT”，还需增加匹配 requestPrincipals 的 AuthorizationPolicy。在 HTTP 路由中，拒绝可能发生于请求认证、授权、TLS 握手，甚至应用自身；只有确认策略作用域、代理记录和应用是否收到该请求，才能说清拒绝位置。

mTLS 工作负载身份、JWT 用户主体与授权规则按不同条件检查，同一条请求可在不同位置被拒绝

把两种身份与两阶段策略拆开测试

仍使用 orders → inventory-v1。先为两个工作负载配置不同 ServiceAccount，确认目标确实启用入站 mTLS；为隔离的测试 JWT 签发者配置 RequestAuthentication，固定 issuer、JWKS、audience，并禁止日志或证据目录保存令牌本身。第一阶段不施加要求令牌的 ALLOW 规则，让带有效令牌、不带令牌、带坏签名令牌的三种请求分别经过库存入站代理。按官方示例的认证语义，前两种可以继续处理，坏令牌会在请求认证处被拒绝；结果若不同，先检查资源是否选中了正确目标。

第二阶段再给同一库存工作负载配置限定来源为 orders 对等身份、且要求有效 requestPrincipals 的 ALLOW 策略。分别发来自正确 ServiceAccount＋有效令牌、错误 ServiceAccount＋有效令牌、正确 ServiceAccount＋无令牌、正确 ServiceAccount＋坏令牌四组请求。每组用不同请求 ID 关联入站代理和库存应用日志：期望第一组允许，第二组因对等身份不符拒绝，第三组因缺少用户主体拒绝，第四组在 JWT 校验阶段拒绝。JWT 校验失败常在 HTTP 层表现为 401，授权拒绝常表现为 403，但应以实际代理详情为准；mTLS 失败可能根本没有 HTTP 响应。

需要比较 DENY 与 ALLOW 时，单独加入一条只针对实验路径的 DENY，证明即使已有 ALLOW 也不会覆盖它；结束前撤回策略，避免后续章节误把遗留规则当新故障。策略声明要连同其命名空间、selector、匹配路径、目标代理当前配置一起保存。对裸 TCP 不要套用要求 HTTP 路径/JWT 的断言。

用例	预期判断依据	实际 HTTP/连接、拒绝位置和应用记录
正确对等身份＋合法 JWT	入站身份、用户主体均匹配	NOT_RUN：无 Kubernetes/Istio/Envoy
错误对等身份＋合法 JWT	mTLS 已认证但授权来源不匹配	NOT_RUN
正确对等身份＋无 JWT	仅配置请求认证时可通过；要求主体后拒绝	NOT_RUN
正确对等身份＋坏 JWT	认证失败，不等同于授权拒绝	NOT_RUN

练习与参考解答

给库存服务加了 RequestAuthentication，匿名请求仍成功，是否说明 JWT 策略失效？参考解答：不一定；该资源验证已携带的令牌，要求必带需要单独的授权条件。
有效 JWT 的请求被拒绝，能否直接换一张 JWT 重试？参考解答：先检查 mTLS 来源、授权策略作用域、请求路径、受众和代理拒绝详情；有效用户令牌并不保证工作负载有权限。