Como autenticar clientes gRPC externos com o Amazon VPC Lattice

O problema é de ponte entre dois modelos de identidade. Clientes externos chegam com JWT, e o Amazon VPC Lattice só confia em assinaturas AWS SigV4, que ele resolve para um principal do IAM e avalia contra auth policies. Dar credenciais AWS a cliente externo quebraria a separação entre identidade externa e interna. Por isso a AWS propõe uma camada de ingress em três peças: um ALB com a ação jwt-validation, uma camada de proxy no ECS com Fargate e auth policies do Lattice por serviço.

O ALB valida assinatura (RS256, com JWKS público), exp, iss e claims extras. Se falhar, devolve 401 antes de gastar computação no backend. O proxy decodifica o payload sem revalidar, converte client_id, scope e sub em headers (x-client-id, x-client-scope, x-client-sub), remove o Bearer e assina com as credenciais da task role. Esses headers entram no SignedHeaders, então não podem ser adulterados. Como o Lattice vê a task role e não o cliente final, as policies controlam qual proxy acessa qual serviço. Há duas formas de assinar: SDK nativo (só RPCs unários, você cuida do framing gRPC) ou filtro aws_request_signing do Envoy (suporta streaming, com target group do Lattice em ProtocolVersion GRPC). No Envoy, o filtro Lua precisa rodar antes do de assinatura, senão os headers de identidade ficam fora da assinatura. O exemplo é para uso fora de produção e leva de 20 a 30 minutos para subir.

Para quem opera plataforma, o ponto crítico é que o proxy é a fronteira de confiança e não revalida token. Na leitura editorial, o security group do proxy aceitando só o ALB deixa de ser detalhe e vira controle central. Em produção, padronizar uma única abordagem de assinatura reduz custo operacional, e o Envoy tende a fazer sentido se streaming estiver no roadmap. Fique de olho também nos custos: ALB, endpoints PrivateLink, Fargate e Lattice cobram enquanto rodam.