云原生中的服务网格如何实现服务间认证令牌传递？

服务网格通过Sidecar代理实现认证令牌传递，利用流量劫持将请求重定向至本地代理，在不修改业务代码的情况下自动注入、读取或修改HTTP头部；控制平面下发策略实现mTLS和身份凭证附加，如JWT或SPIFFE ID，并通过RequestAuthentication和AuthorizationPolicy配置验证与透传规则；经EnvoyFilter等机制将验证后的身份映射为自定义头部（如x-authenticated-user），实现用户身份到应用层的完整透明传递。

服务网格在云原生架构中通过Sidecar代理实现服务间通信的透明管控，认证令牌的传递主要依赖于请求流量的自动拦截与策略执行，无需修改业务代码。

流量劫持与透明代理

服务网格（如Istio）通过注入Sidecar代理（如Envoy）接管服务的进出流量。Pod启动时，网络规则被配置为将所有入站和出站请求重定向到Sidecar。这种透明劫持使得应用发出的原始请求先经过本地代理处理。

当服务A调用服务B时，请求首先到达A的Sidecar，代理可在此阶段读取、添加或修改HTTP头部，包括认证令牌。

自动注入与请求增强

在mTLS启用的情况下，服务网格控制平面（如Istiod）会下发策略，指示Sidecar自动在转发请求时附加必要的身份凭证。例如：

算家云

高效、便捷的人工智能算力服务平台

37

查看详情

• Sidecar可从工作负载证书中提取JWT或SPIFFE ID，并将其作为自定义头（如x-forwarded-identity）插入上游请求
• 若原始请求已携带令牌（如用户登录后的JWT），Sidecar可根据授权策略决定是否透传、替换或删除该令牌
• 使用RequestAuthentication和AuthorizationPolicy资源定义何时需要验证令牌，以及如何向后端服务传递身份信息

安全上下文传递与身份映射

服务网格将底层加密连接中的客户端身份解析为逻辑标识（如spiffe://cluster.local/ns/foo/sa/app1），并可通过Header映射机制将其以特定字段传递给应用。

例如，在Istio中，可以通过EnvoyFilter配置将经过验证的主体信息写入x-authenticated-user等头部，供后端服务审计或个性化处理。

这种方式实现了身份链路的完整传递：用户身份 → 网关认证 → Sidecar验证 → 应用感知，且全程对业务逻辑透明。

基本上就这些，核心是利用数据面代理的能力，在不侵入应用的前提下完成令牌的检查、生成与传递。

以上就是云原生中的服务网格如何实现服务间认证令牌传递？的详细内容，更多请关注php中文网其它相关文章！