Configure a autenticação JWT com JWKS remoto

O Cloud Service Mesh permite-lhe proteger os seus serviços validando tokens da Web JSON (JWT) através do recurso personalizado do Istio RequestAuthentication. Uma parte fundamental desta configuração é o campo jwksUri, que especifica o URI do fornecedor do conjunto de chaves Web JSON (JWKS). Este JWKS contém as chaves públicas usadas para validar os JWTs recebidos.

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

Pré-requisitos para o acesso JWKS externo

Para seguir este guia, precisa do seguinte:

  • Política organizacional para acesso à Internet: se o seu jwksUri apontar para um ponto final da Internet externo, a sua política organizacional Google Cloud tem de permitir o acesso à Internet de saída a partir das suas cargas de trabalho. Em concreto, verifique se a política organizacional constraints/compute.disableInternetNetworkEndpointGroup não está aplicada. Se esta política estiver ativada, a obtenção de JWKS de jwksUris externos falha.

  • Uma carga de trabalho do Kubernetes etiquetada: os recursos RequestAuthentication e AuthorizationPolicy usam um selector para segmentar cargas de trabalho específicas. Tem de ter uma carga de trabalho, como uma implementação do Kubernetes, em execução no cluster com etiquetas que as políticas possam corresponder. Por exemplo, o exemplo httpbin está configurado para ser executado com a etiqueta app: httpbin. Não hesite em usar a configuração com httpbin e curl do guia Token JWT do Istio.

Métodos para ativar a obtenção de JWKS

Existem duas formas principais de configurar a Cloud Service Mesh para permitir que os seus proxies Envoy obtenham chaves JWKS de um jwksUri externo:

Esta é a abordagem recomendada para a maioria dos cenários de produção e é obrigatória para a Cloud Service Mesh com o MCP. Este método dá-lhe controlo explícito sobre a forma como a sua malha interage com o fornecedor JWKS externo.

Defina o serviço externo com um ServiceEntry

Primeiro, tem de criar um ServiceEntry do Istio para tornar o fornecedor JWKS externo um serviço conhecido na sua malha. Este recurso permite a resolução de DNS e o encaminhamento adequado para os proxies Envoy no seu plano de dados.

Para uma política de RequestAuthentication que use jwksUri: "https://your-auth-provider.com/.well-known/jwks.json", 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

Configure as definições de ligação com um DestinationRule

Em segundo lugar, pode precisar de um DestinationRule para especificar as definições de TLS do lado do cliente para as ligações ao fornecedor de JWKS, especialmente se o fornecedor exigir uma configuração de TLS ou mTLS específica.

  • Para fornecedores que usam certificados publicamente fidedignos, crie um DestinationRule com tls.mode definido como SIMPLE para ativar a validação TLS padrão do lado do servidor.
  • Para fornecedores que requerem certificados de cliente (mTLS), defina tls.mode como MUTUAL e indique os caminhos para os certificados e as chaves que o Envoy tem de apresentar.

Esta DestinationRule configura a política de ligação para o ServiceEntry definido no passo 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 estes recursos estão presentes e configurados corretamente, o Envoy usa-os para estabelecer uma ligação segura e obter as chaves JWKS.

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

Se o Cloud Service Mesh não encontrar um ServiceEntry definido pelo utilizador que abranja o nome do anfitrião e a porta de um jwksUri HTTPS numa política RequestAuthentication, configura automaticamente a configuração necessária para o Envoy obter as chaves JWKS. Esta automatização simplifica a configuração para cenários comuns em que a conetividade predefinida ao jwksUri (HTTPS, TLS padrão) é suficiente.

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

  • Está a usar 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 está no cluster.
  • Nenhum elemento visível ServiceEntry (considerando o espaço de nomes da política RequestAuthentication e o campo exportTo do ServiceEntry) já gere o nome de anfitrião e a porta do jwksUri.

Se estas condições forem cumpridas, os seus proxies Envoy são configurados para obter o JWKS sem que tenha de criar recursos ServiceEntry ou DestinationRule explícitos para esse jwksUri.

A configurar RequestAuthentication

Independentemente do método usado para obter JWKS, define as regras de validação de JWT com 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 ver todos os detalhes):

  • issuer: o emissor do JWT.
  • jwksUri: o URI HTTPS do conjunto de chaves públicas (JWKS) do fornecedor.
  • fromHeaders (Opcional): especifica as localizações dos cabeçalhos a partir dos quais o JWT é esperado.
  • fromParams (Opcional): especifica os parâmetros de consulta a partir dos quais o JWT é esperado.
  • forwardOriginalToken (Opcional): se for verdadeiro, o token original é encaminhado para o serviço a montante.

Aplicação da autenticação JWT com AuthorizationPolicy

Para rejeitar pedidos que não tenham um JWT válido, tem de sincronizar a sua política RequestAuthentication com um AuthorizationPolicy. A seguinte política permite pedidos à carga de trabalho your-app apenas se 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 ver exemplos e exemplos de utilização mais detalhados sobre a utilização de reivindicações JWT na autorização, consulte a tarefa de autorização do Istio para tokens JWT.

O que se segue