服务网格中的 mTLS 与访问授权有何区别？

服务网格里，mTLS 和访问授权常被当作同一件事来配置：把所有连接加密之后，核心服务依然接受任意工作负载的调用。两者的分工其实很清楚：mTLS 回答“连接对端是谁、这段流量是否加密”，访问授权回答“这个身份已被验证的对端，能否执行这次调用”。

两条独立的信任判断

mTLS 在传输层建立加密通道，并让接收方校验调用方持有的网格身份。以 Istio 兼容实现为例，PeerAuthentication 可以要求接收方只接受 mTLS 连接；但工作负载被网格纳管、自动获得证书，并不等于该服务已经拒绝明文流量。这是很常见的误读——证书存在只说明具备条件，不代表接收策略已经收紧。

访问授权走的是另一条路径：它依据网格身份、命名空间、服务或请求属性，界定哪些调用方可以访问哪些资源或操作。即使连接已被完整加密，若授权默认放行，所有通过认证的工作负载仍然畅通无阻。

认证通过不等于拥有权限

身份校验通过，只证明对端是网格内的合法成员，不能证明它应该拥有对某个服务的访问权。反过来也成立：再细致的授权规则都不能替代传输加密，因为明文连接上的身份声明缺少可信基础，无法作为判断依据。两类策略必须分别审阅、分别测试，任何一方都不能当作另一方的替代品。

先认证，后授权

实施时通常先收紧传输策略，再收窄授权范围。选择低风险的命名空间或单个工作负载试点，确认调用方身份在策略中如何呈现、策略选择器的实际覆盖范围是否与预期一致，然后按命名空间或服务逐批推进，每批变更后观察连接错误与业务指标。

验证的关键是拿到双向证据：预期调用成功，并留下应用响应与代理连接状态的记录；不符合授权规则的调用被明确拒绝，并能在授权拒绝计数或日志中定位。客户端超时不足以证明策略生效，网络策略、服务发现或应用故障都可能产生相似现象。

用于复核的判断标准

变更完成后，需要分别说明两件事：哪些工作负载要求 mTLS、哪些流量仍绕行网格之外；哪些授权规则实际约束了调用者。前者描述保护边界，后者描述权限边界。mTLS 只覆盖网格策略作用范围内的连接，它既不会自动赋予请求者业务操作权限，也不会让未经过数据平面的路径获得同等保护。把这两个问题分开回答，才算是把策略真正落地。