Istio授权策略细粒度控制

Istio 授权策略的配置往往容易走向两个极端：要么为了省事直接开放全网格，要么为了安全配置了过于宽泛的规则，导致最终效果形同虚设。真正的细粒度控制，核心在于对请求属性（Principal、Source、Path、Header）的精确提取与组合判定。你不需要重写应用代码，只需在 Istio 的 CRD（Custom Resource Definition）中定义好“谁（身份）在什么条件下（触发条件）能对什么（目标服务）做什么（HTTP 方法）”。

Istio 授权策略的评估并非简单的“先到先得”，而是一个明确的优先级模型。首先要搞清楚 CUSTOM、DENY、ALLOW 这三类动作的叠加关系。如果你在网格、命名空间和服务账户级别分别配置了策略，最终的生效结果是它们的交集。具体来说，CUSTOM 动作会先被评估，它通常用于将决策委托给外部授权系统（如 OPA）；如果 CUSTOM 未触发，则评估 DENY 策略，只要有一条 DENY 命中，请求立即被拒绝；最后才是 ALLOW 策略，只有存在一条 ALLOW 策略匹配时，请求才被放行。这意味着，如果你在网格级别设置了一条看似无害的 ALLOW 策略，它实际上会覆盖掉所有没有显式 ALLOW 规则的流量，导致其他服务全部被拒。因此，实施细粒度控制的第一步，往往是先通过 DENY 策略封锁高危端口或路径，再逐步开放 ALLOW 权限。

服务间的身份通常依赖 SPIFFE 格式的 X.509 证书，但面向终端用户的流量控制必须深入到 JWT 的 Payload 层。Istio 的 RequestAuthentication 负责验证 Token 有效性，而 AuthorizationPolicy 则负责提取其中的声明进行判断。真正的细粒度体现在对嵌套声明和数组声明的处理上。例如，假设你的 JWT Payload 中包含一个 groups 字段，值为 ["admin", "editor"]，你想只允许 admin 组访问特定路径。你不能简单地写 values: ["admin"]，因为 Istio 默认对字符串数组做的是完全匹配。正确的做法是利用正则表达式或精确的数组匹配语法。更复杂的场景是结合路径参数进行判断，比如只允许用户访问属于自己 ID 的资源：你可以配置一条规则，提取 JWT 中的 sub 字段，并与 URL 路径中的 userId 进行比对，这需要用到 Istio 的条件匹配语法，将 request.auth.claims["sub"] 与提取出的请求属性做等值判断。

微服务架构中，很多灰度发布或 A/B 测试通过 Header 传递流量标识，但很少有人意识到这些标识可以被授权策略用来做安全隔离。你可以强制要求特定版本的服务只能被带有特定 Header 的内部流量访问。例如，一个金丝雀部署的 v2 版本，只允许在 Header 中带有 X-Canary-Token 且值匹配的请求进入。配置时，在 AuthorizationPolicy 的 when 条件中嵌套 request.headers 属性，并设置精确的字符串匹配。更进一步，你可以利用 Header 中的值做动态匹配，比如检查 X-Request-ID 是否符合 UUID 格式，防止恶意构造的请求穿透到后端。对于 Query 参数，同样的逻辑适用于防止越权访问，比如限制某些敏感操作的执行必须携带一次性 Token 作为 Query 参数，并在策略层面对其格式进行强校验。

在多租户集群中，仅靠 Kubernetes 的 NetworkPolicy 无法实现应用层的细粒度隔离。Istio 的 AuthorizationPolicy 可以精准到服务账户级别。一个常见的错误做法是只针对目标服务（to）配置策略，而忽略了来源（from）的身份限定。要实现真正的零信任，你需要在来源端明确指定 principals。如果你希望 A 命名空间下的所有服务只能访问 B 命名空间下的特定服务，不能直接在 B 命名空间写一条宽泛的允许 A 命名空间的规则，这样会让 A 获得 B 中所有服务的访问权。正确做法是在 B 的特定服务上配置策略，将 from 的 principals 严格限定为 cluster.local/ns/A/sa/specific-service-account。同时，利用 source.namespace 属性进行双重约束，即使服务账户名称相同，不同命名空间下的身份也天然隔离。这种基于服务账户的强制访问控制，是防止容器逃逸后横向移动的关键手段。

RESTful API 的语义决定了 GET 和 POST 的安全级别完全不同。细粒度控制必须做到方法级别的区分。Istio 允许在一条策略中对同一个路径配置不同的方法限制。例如，/api/data 路径允许 GET 请求，但 POST 和 DELETE 请求仅限管理员服务账户。配置时，你需要在 rules 下拆分为多个条目，每个条目针对不同的 methods 字段设置不同的来源条件。更深层的控制在于路径的模式匹配。Istio 支持通配符（*）和双通配符（），但两者的安全含义差异巨大。使用 * 只能匹配当前路径层级，不会跨越斜杠；而 会递归匹配所有子路径。如果你只想开放 /public 下的直接资源，却误用了 /public/，就会意外暴露 /public/internal/config 这样的敏感端点。因此，建议始终优先使用精确路径，在必须使用通配符时，用具体的后缀限制来缩小暴露面。

静态的规则匹配无法应对复杂的业务逻辑，Istio 的 when 条件块支持对多个属性进行逻辑与（AND）组合，但原生不支持显式的 OR。要实现 OR 逻辑，需要拆分多条 rules。真正体现细粒度控制精髓的是对请求上下文的深度利用。你可以检查 request.host 来区分同一服务暴露的不同域名，也可以检查 connection.sni 来对 TLS 握手阶段的域名做准入。一个典型的实战场景是防止 SSRF（Server-Side Request Forgery）攻击：在网格内部，你可以编写策略检查请求的原始目标 IP 或目标端口，如果检测到请求试图访问内网元数据服务（如 169.254.169.254）或非标准端口，直接触发 DENY 动作。这需要配置 when 条件中的 destination.ip 或 destination.port 属性，并将其与一组黑名单进行匹配。

当 Istio 内置的条件匹配无法满足需求时，CUSTOM 动作允许将决策权交给外部授权服务。但这不意味着你可以把粗粒度的请求直接扔给外部服务，那样会造成严重的性能瓶颈。正确的做法是在 Istio 层面先做一层粗筛，只将需要深度鉴权的特定路径转发给外部服务。在配置 CUSTOM 策略时，你可以通过 match 条件限定只针对高风险操作（如涉及资金或敏感数据的 POST 请求）触发外部检查。同时，外部授权服务返回的 HTTP 响应头可以注入到后续的请求流中，供业务代码直接使用，这需要你在外部服务中返回 OkHttpResponse 时带上 headers_to_add 字段。这种架构既保证了灵活性，又避免了外部服务成为单点故障。

配置完策略后，直接上生产环境验证是极其危险的。Istio 提供了针对 AuthorizationPolicy 的试运行模式，但更实用的方法是通过日志和访问审计来观察策略的实际命中情况。你可以临时开启 Envoy 的 RBAC 调试日志，查看具体的拒绝原因。在配置层面，一个常见的排查技巧是使用条件匹配中的 notValues 或 notPorts 来验证反向逻辑。如果你怀疑某条策略过于宽松，可以临时创建一条更严格的 DENY 策略，观察是否有合法流量被误拦。此外，利用 Istioctl 的 authz check 命令可以模拟特定服务账户对特定路径的访问结果，这能在不实际发起网络请求的情况下，快速验证策略组合后的最终生效逻辑。记住，细粒度控制不是一次性配置，而是一个持续收紧、持续验证的过程。