Configurer l'authentification JWT avec JWKS distant

Cloud Service Mesh vous permet de sécuriser vos services en validant les jetons Web JSON (JWT) à l'aide de la ressource personnalisée Istio RequestAuthentication. Un élément clé de cette configuration est le champ jwksUri, qui spécifie l'URI du fournisseur de l'ensemble de clés Web JSON (JWKS). Ce JWKS contient les clés publiques utilisées pour valider les jetons JWT entrants.

Important : Dans Cloud Service Mesh, le plan de données (proxies Envoy) est chargé de récupérer les clés JWKS directement à partir de jwksUri. Le plan de contrôle Cloud Service Mesh (géré par Traffic Director) n'effectue pas d'appels externes pour récupérer ces clés. Cela signifie que toutes les communications réseau avec les fournisseurs JWKS externes proviennent du proxy Envoy de votre charge de travail.

Conditions requises pour l'accès externe aux JWKS

Pour suivre ce guide, vous aurez besoin des éléments suivants :

  • Règle d'organisation pour l'accès à Internet : si votre jwksUri pointe vers un point de terminaison Internet externe, la règle de votre organisation Google Cloud doit autoriser l'accès à Internet sortant depuis vos charges de travail. Plus précisément, vérifiez que la règle d'administration constraints/compute.disableInternetNetworkEndpointGroup n'est pas appliquée. Si cette règle est activée, la récupération de JWKS à partir de jwksUri externes échouera.

  • Charge de travail Kubernetes avec libellé : les ressources RequestAuthentication et AuthorizationPolicy utilisent un selector pour cibler des charges de travail spécifiques. Vous devez disposer d'une charge de travail (par exemple, un déploiement Kubernetes) exécutée dans votre cluster avec des libellés auxquels les règles peuvent correspondre. Par exemple, l'exemple httpbin est configuré pour s'exécuter avec le libellé app: httpbin. N'hésitez pas à utiliser la configuration avec httpbin et curl du guide Jeton JWT Istio.

Méthodes d'activation de la récupération des JWKS

Il existe deux façons principales de configurer Cloud Service Mesh pour permettre à vos proxys Envoy d'extraire les clés JWKS d'un jwksUri externe :

Cette approche est recommandée pour la plupart des scénarios de production et est obligatoire pour Cloud Service Mesh avec MCP. Cette méthode vous permet de contrôler explicitement la manière dont votre maillage interagit avec le fournisseur JWKS externe.

Définir le service externe avec un ServiceEntry

Vous devez d'abord créer un ServiceEntry Istio pour faire du fournisseur JWKS externe un service connu dans votre maillage. Cette ressource permet la résolution DNS et le routage approprié pour les proxys Envoy de votre plan de données.

Pour une règle RequestAuthentication qui utilise jwksUri: "https://your-auth-provider.com/.well-known/jwks.json", vous devez créer le ServiceEntry suivant :

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

Configurer les paramètres de connexion avec un DestinationRule

Deuxièmement, vous aurez peut-être besoin d'un DestinationRule pour spécifier les paramètres TLS côté client pour les connexions au fournisseur JWKS, en particulier si le fournisseur exige une configuration TLS ou mTLS spécifique.

  • Pour les fournisseurs utilisant des certificats publiquement approuvés, créez un DestinationRule avec tls.mode défini sur SIMPLE pour activer la validation TLS standard côté serveur.
  • Pour les fournisseurs qui exigent des certificats client (mTLS), définissez tls.mode sur MUTUAL et indiquez les chemins d'accès aux certificats et aux clés qu'Envoy doit présenter.

Cette DestinationRule configure la règle de connexion pour le ServiceEntry défini à l'étape précédente :

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

Lorsque ces ressources sont présentes et correctement configurées, Envoy les utilise pour établir une connexion sécurisée et récupérer les clés JWKS.

2. Configuration automatique par Cloud Service Mesh (Traffic Director uniquement)

Si Cloud Service Mesh ne trouve pas de ServiceEntry défini par l'utilisateur qui couvre le nom d'hôte et le port d'un jwksUri HTTPS dans une règle RequestAuthentication, il configure automatiquement la configuration nécessaire pour qu'Envoy récupère les clés JWKS. Cette automatisation simplifie la configuration pour les scénarios courants où la connectivité par défaut à jwksUri (HTTPS, TLS standard) est suffisante.

Conditions pour la configuration automatique : ce comportement automatique s'applique si :

  • Vous utilisez Cloud Service Mesh avec Traffic Director.
  • jwksUri utilise le schéma https.
  • jwksUri pointe vers un service externe qui n'est pas local au cluster.
  • Aucun ServiceEntry visible (en tenant compte de l'espace de noms de la règle RequestAuthentication et du champ exportTo de ServiceEntry) ne gère déjà le nom d'hôte et le port de jwksUri.

Si ces conditions sont remplies, vos proxys Envoy seront configurés pour récupérer les JWKS sans que vous ayez à créer de ressources ServiceEntry ou DestinationRule explicites pour ce jwksUri.

Configuration de RequestAuthentication

Quelle que soit la méthode utilisée pour récupérer les JWKS, vous définissez les règles de validation JWT à l'aide d'une règle 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"

Champs clés dans jwtRules (pour en savoir plus, consultez la documentation Istio RequestAuthentication) :

  • issuer : émetteur du jeton JWT.
  • jwksUri : URI HTTPS de l'ensemble de clés publiques (JWKS) du fournisseur.
  • fromHeaders (facultatif) : spécifie les emplacements d'en-tête à partir desquels le jeton JWT est attendu.
  • fromParams (facultatif) : spécifie les paramètres de requête à partir desquels le jeton JWT est attendu.
  • forwardOriginalToken (facultatif) : si la valeur est "true", le jeton d'origine est transmis au service en amont.

Appliquer l'authentification JWT avec AuthorizationPolicy

Pour refuser les requêtes qui ne comportent pas de jeton JWT valide, vous devez associer votre stratégie RequestAuthentication à un AuthorizationPolicy. La règle suivante autorise les requêtes adressées à la charge de travail your-app uniquement si elles présentent un jeton JWT valide de l'émetteur et du sujet spécifiés.

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

Pour obtenir des exemples et des cas d'utilisation plus détaillés sur l'utilisation des revendications JWT dans l'autorisation, consultez la tâche d'autorisation Istio pour les jetons JWT.

Étape suivante