Istio AuthorizationPolicy 配置ALLOW/DENY动作效果反向原因解析

• 按配置预期，设置action: ALLOW的AuthorizationPolicy应该仅放行default命名空间下checking-account服务，发往标签为app: transactions的工作负载的GET路径请求，但实际运行效果是该工作负载直接拒绝了checking-account的所有合法访问。
• 把策略的action修改为DENY后，按照预期应该拦截checking-account的对应请求，实际运行效果却是该工作负载完全放行所有来源的请求，包括本该被拦截的checking-account流量，策略生效效果和预期完全反向。
• 本次复现用到的策略配置如下：

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-transactions-authorizationpolicy
  namespace: default
spec:
  selector:
    matchLabels:
      app: transactions
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/checking-account"]
    to:
    - operation:
       methods: ["GET"]
       paths: ["/*"]

整个反向效果是两个问题叠加导致的：

• 规则存在永久匹配失败的格式错误
  Istio识别的服务身份（principal）有固定的格式规范，标准结构为cluster.local/ns/<目标命名空间>/sa/<服务账号名称>。上述配置中填写的principal值cluster.local/ns/default/checking-account缺失了关键的sa/路径段，和实际从请求中提取的服务身份字符串完全不匹配，导致这条规则永远无法命中任何真实流量，相当于策略内的放行/拦截规则实际为空。
• 对AuthorizationPolicy的默认生效逻辑存在认知偏差
  • 当目标工作负载上存在至少一个action: ALLOW类型的策略时，网格会自动从默认的「全量放行」模式切换为白名单拦截模式：默认拒绝所有请求，仅对被任意一条ALLOW规则明确匹配的请求开放访问。由于当前规则永久匹配失败，没有任何请求能满足放行条件，因此包括checking-account在内的所有请求都会被拒绝，最终呈现「ALLOW策略反而拦截合法流量」的效果。
  • 当目标工作负载上不存在任何action: ALLOW类型的策略时（比如将现有策略的action修改为DENY），网格会回到「全量放行」的默认模式：仅拒绝被任意一条DENY规则明确匹配的请求，其余所有请求正常放行。由于当前DENY规则同样永久匹配失败，没有任何请求满足拦截条件，因此所有请求（包括本该被拦截的checking-account流量）都会被正常放行，最终呈现「DENY策略反而放行流量」的反向效果。

• 修正principal的格式错误，将规则中的principal值调整为正确格式cluster.local/ns/default/sa/checking-account，可以通过istioctl x describe pod <transactions对应Pod名称>的输出，核对目标工作负载实际识别到的源请求principal值，确保配置值和实际值完全匹配。
• 配置完成后可分别验证ALLOW、DENY模式的生效逻辑：规则能正常匹配流量时，ALLOW模式下仅放行符合规则的请求，DENY模式下仅拦截符合规则的请求，即可消除反向生效的异常。

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