Istio 1.6.2中Authorization Policy的DENY规则对有效JWT不生效

首先明确你配置的这个DENY规则的预期行为：
当请求携带的JWT令牌中iss声明等于https://dev-n63ipah2.us.auth0.com/时，该请求会被直接拒绝访问dex-ms-contact服务——不管这个JWT是否有效，只要request.auth.claims[iss]匹配到指定值，就会触发DENY动作。

但从你的描述来看，这个规则没有生效，结合Istio 1.6.2的特性，可能的原因和排查方向如下：

1. 后端服务的RequestAuthentication未生效 #

你的dex-ms-contact-jwt RequestAuthentication需要先成功验证JWT，才能生成request.auth.claims[iss]这个属性，否则DENY规则的when条件永远不满足，自然不会触发拒绝。

• 检查Pod标签：确认dex-ms-contact的Pod带有app: dex-ms-contact标签（和RequestAuthentication的selector匹配）
• 检查Sidecar注入：执行 kubectl get pods -n default -l app=dex-ms-contact，确认每个Pod都有istio-proxy容器
• 验证认证策略状态：用 istioctl authn check <pod-name> -n default，查看输出中是否包含你的JWT认证规则

2. JWT未正确传递到后端服务 #

IngressGateway验证JWT后，默认会将认证信息传递给下游，但如果请求在转发过程中丢失了JWT或者相关认证上下文，后端的RequestAuthentication无法获取到有效令牌，也就无法生成request.auth.claims[iss]。

• 查看Sidecar日志：执行 kubectl logs <pod-name> -c istio-proxy -n default，搜索JWT相关日志，比如JWT authentication failed或者JWT is valid，确认后端是否接收到并验证了JWT

3. Authorization Policy的匹配逻辑问题 #

Istio的Authorization Policy执行顺序是：先检查所有DENY规则，匹配则拒绝；再检查ALLOW规则，匹配则允许；无匹配规则时默认允许。
如果你的DENY规则的selector没有正确匹配到服务的Pod，规则根本不会作用于目标服务。可以执行 kubectl get authorizationpolicy dex-ms-contact-require-jwt -n default -o yaml，核对selector的labels是否和Pod的labels完全一致。

补充：如果你的实际需求是拒绝未携带有效JWT的请求 #

如果你的真实意图是只允许携带有效JWT的请求访问服务，那当前的DENY规则逻辑是反的——你应该配置ALLOW规则允许合法JWT请求，同时显式DENY所有未通过认证的请求：

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: dex-ms-contact-allow-jwt
  namespace: default
spec:
  selector:
    matchLabels:
      app: dex-ms-contact
  action: ALLOW
  rules:
  - when:
    - key: request.auth.claims[iss]
      values: ["https://dev-n63ipah2.us.auth0.com/"]
---
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: dex-ms-contact-deny-all
  namespace: default
spec:
  selector:
    matchLabels:
      app: dex-ms-contact
  action: DENY
  rules:
  - {}

内容的提问来源于stack exchange，提问作者Sweta Sharma