背景与问题

外部gRPC客户端通常携带JSON Web Token（JWT）进行身份认证，而Amazon VPC Lattice服务网络内部信任AWS Signature Version 4（SigV4）签名，并将每个调用者解析为IAM主体。直接给外部客户端AWS凭证会破坏内外身份隔离。因此需要在边缘层验证JWT，并将验证后的身份转换为VPC Lattice信任的SigV4签名，同时保持端到端gRPC over HTTP/2帧。

参考架构

方案使用入口VPC与后端VPC通过VPC Lattice服务网络互联：

  • 入口层：Application Load Balancer（ALB）利用jwt-validation动作校验访问令牌，并按gRPC路径路由到代理层。
  • 代理层：运行在Amazon ECS on Fargate上的代理服务解码JWT声明，将其转为稳定HTTP头，并使用ECS任务角色凭证对出站请求进行SigV4签名。VPC Lattice将任务角色视为工作负载身份。
  • 后端服务：两个示例gRPC服务（用户服务、订单服务）注册为VPC Lattice服务，各自配备IAM鉴权策略，仅允许特定代理路径访问。

身份提供商可采用Amazon Cognito或其他OIDC兼容提供商（需RS256签名及公开JWKS）。

两种SigV4签名实现

文章探讨两种签名方法，均映射到独立任务角色、ALB路径与后端服务，以证明不同签名方式均能产生VPC Lattice可解析的正确IAM主体：

  1. 原生AWS SDK签名：使用SdkTaskRole，ALB路径/sdk.*，对应User Service。
  2. Envoy签名过滤器：使用EnvoyTaskRole，ALB路径/envoy.*，对应Order Service。

生产环境建议统一一种签名方式以降低运维复杂度，但按服务授权策略仍可用于隔离工作负载。

请求流程示例

外部客户端通过OAuth 2.0 client_credentials授权从Cognito获取JWT，随后通过HTTP/2向ALB发送gRPC请求，将JWT作为authorization元数据头传递。ALB验证令牌并转发至代理，代理签名后由VPC Lattice鉴权抵达后端。

示例JWT包含sub、scope、iss等声明，scope限定客户端权限。gRPC元数据以HTTP/2头原生承载，无需特殊编码。

部署与注意事项

部署需具备VPC、ALB、ECS、VPC Lattice、Cognito等经验，以及ACM证书、Docker Hub令牌等前置条件。配套CloudFormation模板与测试脚本可构建镜像并验证各层允许合法请求、拒绝非法请求。该示例用于非生产，启用了反射、ECS Exec等简化设置，产生费用需及时清理。

对读者的意义 / 技术解读

对于运维与网络工程师，该架构展示了在混合身份边界下桥接外部机器到机器认证与云内IAM授权的典型模式。虽然本站聚焦网络诊断工具（如Ping、Tcping、HTTP测速等），但理解此类gRPC网关与代理签名机制，有助于在排查跨VPC服务调用失败、HTTP/2连接中断或TLS证书问题时，快速定位是身份校验还是网络连通性故障。此外，ALB的JWT验证与VPC Lattice的细粒度授权策略，为设计零信任网络提供了可借鉴的控制点，在规划外部客户端接入内部服务时，应优先考虑身份联合而非凭证透传。