在云原生架构里，服务网格把原本散落在各个微服务中的通信控制逻辑集中到独立的基础设施层。策略执行正是这一层最核心的能力之一，它决定了谁可以访问哪个服务、访问频率上限是多少、传输是否必须加密等。不同于在代码里硬编码判断，服务网格通过边车代理拦截所有进出流量，在代理内部完成策略匹配与动作实施。
控制平面与数据平面的分工
服务网格通常采用控制平面加数据平面的架构。控制平面如Istio的istiod负责接收用户声明的策略对象，例如AuthorizationPolicy、RateLimitPolicy，并将其翻译成数据平面代理能够理解的配置格式。数据平面一般由每个Pod中的Envoy边车组成，它们根据下发的配置在请求链路中实时执行策略。
这种分工带来明显好处：业务容器不需要引入任何安全SDK，也不需要在每次发布时重新编译鉴权逻辑。策略的修改只作用在控制平面生成的配置上，通过xDS协议推送到代理，整个过程对应用透明。当集群规模扩大时，策略依旧只在控制平面维护一份事实来源，避免了多服务各自实现的偏差。
基于CRD的策略声明方式
在Istio中，策略多用自定义资源定义（CRD）描述。下面是一段限制特定命名空间调用的授权策略示例：
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: deny-from-other-ns
namespace: default
spec:
selector:
matchLabels:
app: payment
action: DENY
rules:
- from:
- source:
notNamespaces: ["default"]
上面这段配置表达的含义是：对于带有app=payment标签的工作负载，拒绝所有来自非default命名空间的请求。控制平面会把它转为Envoy的RBAC过滤器配置。需要注意的是，action字段支持ALLOW和DENY，且DENY优先级高于ALLOW，这是很多初学者容易混淆的点。
除了访问控制，限流策略也常通过网格实现。某些方案使用自定义的EnvoyFilter或直接对接外部限流服务。无论如何声明，最终都落在代理对请求头、路径、源身份的匹配上，再由代理决定是否转发、拒绝或延迟响应。
请求在代理中的执行顺序
当一个请求从客户端Pod发出，它会先进入本地边车，经一系列过滤器链处理。典型的顺序包括：身份认证过滤器确认来源身份，RBAC过滤器做授权判断，限流过滤器检查配额，最后才路由到目标服务的边车。目标边车再次执行入站策略，形成双向控制。
理解这个顺序有助于排查问题。例如某次调用返回403，应先确认是否是出站侧DENY规则命中，还是入站侧ALLOW规则缺失。通过代理的管理接口查看生效配置，比直接改业务代码更高效。如下代码片段展示如何用管理员接口查询当前授权配置：
# 进入边车容器查看生效的监听器配置摘要 istioctl proxy-config listeners payment-7d8f9c6b4-x2k9p --port 15006 -o json # 查看rbac过滤器的简要信息 istioctl proxy-config routes payment-7d8f9c6b4-x2k9p -o json | grep -i rbac
通过这类命令，可以确认策略是否真正下发到了数据平面。如果控制平面配置正确但代理未生效，通常是xDS推送延迟或版本兼容问题，而非策略写法错误。
策略执行的优势与局限
将策略执行外置到服务网格，最大优势是统一与解耦。安全团队可以独立迭代访问规则，业务团队不被打断。同时，由于策略在代理层强制实施，即使某个服务存在漏洞绕过自身校验，网格仍能兜底拦截越权流量。
不过也要看到局限。引入边车会增加每次调用的网络跳转与资源占用，在超高性能场景下需评估延迟成本。另外，过于细碎的策略会让控制平面配置膨胀，影响下发效率。因此在设计时需平衡粒度，优先覆盖跨域、敏感接口等高频风险点，而不是对每一个内部方法都设限。
落地建议
对于刚开始使用服务网格的团队，建议先从简单的命名空间隔离策略入手，验证控制平面与代理的协同。之后再逐步加入基于请求路径的细粒度授权和全局限流。过程中保持策略命名规范，并借助网格自带的遥测能力观察拒绝事件，才能把策略执行真正用稳。
总体来看，云原生中的服务网格通过控制平面集中编排、数据平面透明拦截的方式，把策略执行变成基础设施的天然能力。掌握其声明语法与执行链路，是构建安全可观测系统的关键一步。
service_meshpolicy_enforcementistio修改时间：2026-08-06 04:39:29