Configurar a autenticação JWT com JWKS remotos

Com o Cloud Service Mesh, é possível proteger seus serviços validando JSON Web Tokens (JWT) usando o recurso personalizado RequestAuthentication do Istio. Uma parte fundamental dessa configuração é o campo jwksUri, que especifica o URI do provedor do conjunto de chaves da Web JSON (JWKS, na sigla em inglês). Esse JWKS contém as chaves públicas usadas para validar os JWTs recebidos.

Importante: no Cloud Service Mesh, o plano de dados (proxies do Envoy) é responsável por buscar as chaves JWKS diretamente do jwksUri. O plano de controle do Cloud Service Mesh (gerenciado pelo Traffic Director) não faz chamadas externas para buscar essas chaves. Isso significa que toda a comunicação de rede com provedores JWKS externos tem origem no proxy Envoy da sua carga de trabalho.

Pré-requisitos para acesso externo ao JWKS

Para seguir este guia, você precisa:

  • Política organizacional para acesso à Internet: se o jwksUri apontar para um endpoint externo da Internet, a política organizacional do Google Cloud precisa permitir o acesso à Internet de saída das suas cargas de trabalho. Especificamente, verifique se a política da organização constraints/compute.disableInternetNetworkEndpointGroup não está sendo aplicada. Se essa política estiver ativada, a busca de JWKS de jwksUris externos vai falhar.

  • Uma carga de trabalho do Kubernetes rotulada: os recursos RequestAuthentication e AuthorizationPolicy usam um selector para segmentar cargas de trabalho específicas. Você precisa ter uma carga de trabalho, como uma implantação do Kubernetes, em execução no cluster com rótulos que as políticas possam corresponder. Por exemplo, a amostra httpbin está configurada para ser executada com o rótulo app: httpbin. Use a configuração com httpbin e curl do guia Token JWT do Istio.

Métodos para ativar a busca de JWKS

Há duas maneiras principais de configurar o Cloud Service Mesh para permitir que seus proxies Envoy busquem chaves JWKS de um jwksUri externo:

Essa é a abordagem recomendada para a maioria dos cenários de produção e é obrigatória para o Cloud Service Mesh com MCP. Esse método oferece controle explícito sobre como a malha interage com o provedor JWKS externo.

Definir o serviço externo com um ServiceEntry

Primeiro, crie um ServiceEntry do Istio para tornar o provedor JWKS externo um serviço conhecido na sua malha. Esse recurso permite a resolução de DNS e o roteamento adequado para os proxies Envoy no seu plano de dados.

Para uma política RequestAuthentication que usa jwksUri: "https://your-auth-provider.com/.well-known/jwks.json", você criaria o seguinte ServiceEntry:

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: "external-jwks-provider-se"
  namespace: your-namespace 
spec:
  hosts:
  - "your-auth-provider.com" # Hostname from your jwksUri
  location: MESH_EXTERNAL
  ports:
  - number: 443
    name: https
    protocol: TLS
  resolution: DNS

Configurar as definições de conexão com um DestinationRule

Em segundo lugar, talvez seja necessário um DestinationRule para especificar as configurações de TLS do lado do cliente para conexões com o provedor JWKS, principalmente se ele exigir uma configuração específica de TLS ou mTLS.

  • Para provedores que usam certificados confiáveis publicamente, crie um DestinationRule com tls.mode definido como SIMPLE para ativar a validação TLS padrão do lado do servidor.
  • Para provedores que exigem certificados de cliente (mTLS), defina tls.mode como MUTUAL e forneça os caminhos para os certificados e as chaves que o Envoy precisa apresentar.

Essa DestinationRule configura a política de conexão para o ServiceEntry definido na etapa anterior:

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: "external-jwks-provider-dr"
  namespace: your-namespace 
spec:
  host: "your-auth-provider.com" # Must match a host in the ServiceEntry
  trafficPolicy:
    tls:
      # Use SIMPLE for standard server-side TLS.
      mode: SIMPLE 
      
      # If the JWKS provider uses a custom CA, provide the CA cert bundle.
      # caCertificates: /path/to/provider-ca-cert.pem

      # For providers requiring mTLS from Envoy, uncomment the following:
      # mode: MUTUAL
      # clientCertificate: /path/to/client-cert.pem
      # privateKey: /path/to/client-key.pem
      # caCertificates: /path/to/provider-ca-cert.pem

Quando esses recursos estão presentes e configurados corretamente, o Envoy os usa para estabelecer uma conexão segura e buscar as chaves JWKS.

2. Configuração automática pelo Cloud Service Mesh (somente Traffic Director)

Se o Cloud Service Mesh não encontrar um ServiceEntry definido pelo usuário que cubra o nome do host e a porta de um jwksUri HTTPS em uma política RequestAuthentication, ele vai configurar automaticamente a configuração necessária para o Envoy buscar as chaves JWKS. Essa automação simplifica a configuração para cenários comuns em que a conectividade padrão com o jwksUri (HTTPS, TLS padrão) é suficiente.

Condições para a configuração automática: esse comportamento automático se aplica se:

  • Você está usando o Cloud Service Mesh com o Traffic Director.
  • O jwksUri usa o esquema https.
  • O jwksUri aponta para um serviço externo que não é local do cluster.
  • Nenhum ServiceEntry visível (considerando o namespace da política RequestAuthentication e o campo exportTo do ServiceEntry) já gerencia o nome do host e a porta do jwksUri.

Se essas condições forem atendidas, os proxies Envoy serão configurados para buscar os JWKS sem exigir que você crie recursos ServiceEntry ou DestinationRule explícitos para esse jwksUri.

Configurando RequestAuthentication

Independente do método usado para buscar JWKS, você define regras de validação de JWT usando uma política RequestAuthentication.

apiVersion: security.istio.io/v1
kind: RequestAuthentication
metadata:
  name: "jwt-example"
  namespace: your-namespace # Replace with your application's namespace
spec:
  selector:
    matchLabels:
      app: your-app # Replace with your application's label (e.g. httpbin)
  jwtRules:
  - issuer: "testing@secure.istio.io"
    jwksUri: "https://raw.githubusercontent.com/istio/istio/release-1.26/security/tools/jwt/samples/jwks.json"

Campos principais em jwtRules. Consulte a documentação do Istio RequestAuthentication para mais detalhes.

  • issuer: o emissor do JWT.
  • jwksUri: o URI HTTPS do conjunto de chaves públicas (JWKS) do provedor.
  • fromHeaders (opcional): especifica os locais de cabeçalho de onde o JWT é esperado.
  • fromParams (opcional): especifica os parâmetros de consulta de que o JWT é esperado.
  • forwardOriginalToken (opcional): se for "true", o token original será encaminhado ao serviço upstream.

Aplicar a autenticação JWT com AuthorizationPolicy

Para rejeitar solicitações sem um JWT válido, pareie sua política RequestAuthentication com um AuthorizationPolicy. A política a seguir permite solicitações para a carga de trabalho your-app somente se elas apresentarem um JWT válido do emissor e assunto especificados.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
 name: "require-jwt-for-your-app"
 namespace: your-namespace # Replace with your application's namespace
spec:
 selector:
   matchLabels:
     app: your-app # Replace with your application's label (e.g. httpbin)
 action: ALLOW
 rules:
 - from:
   - source:
       # This principal is typically in the format "issuer/subject"
       requestPrincipals: ["testing@secure.istio.io/sub-from-jwt"] # Replace with the expected principal

Para exemplos e casos de uso mais detalhados sobre como usar declarações JWT na autorização, consulte a tarefa de autorização do Istio para tokens JWT.

A seguir