istio authorizationpolicy是实现微服务间极细粒度防越权访问控制的核心方案，基于mtls认证后的服务身份、http路径与方法等多维条件进行精确授权，如仅允许订单服务以post方式调用支付服务的/charge接口，并拒绝所有对/admin/路径的访问。
要实现微服务间极细粒度的防越权访问控制，不能只靠传统防火墙或粗粒度网络层策略，而需结合服务身份、请求上下文、资源路径和操作动词等多维条件，在服务网格或 API 网关层面落地。核心思路是：**用服务身份代替 IP 地址，用意图代替端口，用资源路径+HTTP 方法代替协议类型**。
基于 Istio AuthorizationPolicy 的路径级控制
这是目前最成熟的细粒度方案之一，适用于已接入 Istio 服务网格的环境。它不依赖客户端 IP，而是基于 mTLS 认证后的服务身份（如 cluster.local/ns/order-ns/sa/order-service）做授权决策，并精确到 HTTP 路径与方法。
- 只允许订单服务调用支付服务的
/charge接口，且仅限POST方法 - 拒绝所有对
/admin/前缀路径的访问，无论来源服务是谁 - 可叠加多个规则，例如：同一服务在不同命名空间下拥有不同权限
借助 Spring Cloud Gateway + 自定义鉴权 Filter
若未使用服务网格，但网关统一入口明确，可在 Spring Cloud Gateway 层嵌入动态鉴权逻辑。关键在于把 JWT 中的 scope 或自定义声明（如 "perm:payment:charge:create"）与路由元数据绑定。
- 为每个路由配置
metadata.permissions，例如["payment:read", "order:write"] - 编写
GlobalFilter解析 JWT，提取用户角色与权限列表，再比对当前请求所需权限 - 支持 SpEL 表达式，例如
@authService.hasPermission(#path, #method, 'payment')，实现运行时判断
Consul Connect 意图（Intentions）+ ACL 组合策略
Consul 的意图机制天然面向服务身份，配合 ACL 可实现“谁可以调用谁的哪些接口”的语义化控制。虽然原生意图不直接识别路径，但可通过 Sidecar 代理注入自定义 header 或标签，在 ACL 规则中引用。
- 先启用 ACL 并创建策略，例如允许
order服务读取payment服务的健康状态和服务元数据 - 定义意图：
order → payment允许，但需 Sidecar 在转发时附加X-Allowed-Endpoint: /charge - 在 Consul ACL 规则中使用
service "payment" { policy = "read" }，并配合外部策略引擎（如 Open Policy Agent）校验 header
Kubernetes NetworkPolicy 的补充约束
NetworkPolicy 是底层网络隔离的必要补充，虽无法识别 HTTP 路径，但能防止绕过网关或服务网格的直连攻击。建议作为“兜底防线”而非主控手段。
- 限制前端 Pod 只能通过 ClusterIP 访问后端 API 的特定端口（如 8080），禁止访问数据库端口（5432）
- 使用
ipBlock阻断已知恶意 CIDR 段，或用namespaceSelector隔离测试环境与生产环境 - 必须配合 CNI 插件（如 Calico）启用 egress 控制，否则默认放行所有出向流量
