服务网格通过Sidecar代理实现mTLS加密，控制平面签发SPIFFE标准证书，支持策略驱动的加密模式配置，如Istio的PeerAuthentication设置STRICT模式，全程对应用透明。
服务网格在云原生架构中通过透明的双向TLS（mTLS）实现服务间流量加密，无需修改应用代码即可保障微服务通信的安全性。
基于Sidecar代理自动启用mTLS
服务网格（如Istio、Linkerd）将网络通信能力从应用中剥离，通过在每个服务实例旁部署Sidecar代理（如Envoy）接管所有进出流量。这些代理在建立连接时自动协商并启用mTLS：
- 服务A发出的请求先由其Sidecar接收
- Sidecar与目标服务B的Sidecar建立安全通道
- 数据在两个代理之间以加密形式传输
- 目标Sidecar解密后转发给服务B
整个过程对应用完全透明，业务代码不感知加密逻辑。
证书与身份管理机制
服务网格内置身份认证体系，确保只有合法服务才能参与通信：
- 控制平面（如Istio的Citadel）为每个服务签发唯一证书
- 证书基于SPIFFE标准，标识服务身份（如spiffe://cluster/ns/default/sa/productsvc）
- Sidecar定期轮换密钥和证书，提升安全性
- 连接建立时双方验证证书有效性及身份权限
这种基于身份的加密替代了传统IP/端口信任模型，更适应动态编排环境。
策略驱动的加密控制
管理员可通过配置策略灵活管理加密行为：
- 定义命名空间或服务级别的mTLS模式（ STRICT / PERMISSIVE / DISABLE ）
- 在迁移过程中允许部分服务明文通信（PERMISSIVE），逐步过渡到全加密
- 结合授权策略，限制特定服务间的访问关系
例如在Istio中，通过PeerAuthentication策略启用命名空间级强加密：
apiVersion: security.istio.io/v1beta1kind: PeerAuthentication
metadata:
name: default
spec:
mtls:
mode: STRICT
基本上就这些。服务网格把加密做到基础设施层，既保证了安全又解放了开发者。只要平台配好策略，服务之间自动安全通信，不用每个团队重复造轮子。
