Configurare l'autenticazione JWT con JWKS remoto

Cloud Service Mesh consente di proteggere i servizi convalidando i token web JSON (JWT) utilizzando la risorsa personalizzata RequestAuthentication di Istio. Una parte fondamentale di questa configurazione è il campo jwksUri, che specifica l'URI del fornitore del set di chiavi web JSON (JWKS). Questo JWKS contiene le chiavi pubbliche utilizzate per convalidare i JWT in entrata.

Importante: in Cloud Service Mesh, il data plane (proxy Envoy) è responsabile del recupero delle chiavi JWKS direttamente da jwksUri. Il control plane di Cloud Service Mesh (gestito da Traffic Director) non effettua chiamate esterne per recuperare queste chiavi. Ciò significa che tutta la comunicazione di rete con i provider JWKS esterni ha origine dal proxy Envoy del tuo workload.

Prerequisiti per l'accesso JWKS esterno

Per seguire questa guida, devi disporre di:

  • Policy dell'organizzazione per l'accesso a internet: se il tuo jwksUri punta a un endpoint internet esterno, la policy dell'organizzazione Google Cloud deve consentire l'accesso a internet in uscita dai tuoi workload. In particolare, verifica che il criterio dell'organizzazione constraints/compute.disableInternetNetworkEndpointGroup non sia applicato. Se questo criterio è attivato, il recupero di JWKS da jwksUri esterni non andrà a buon fine.

  • Un workload Kubernetes etichettato: le risorse RequestAuthentication e AuthorizationPolicy utilizzano un selector per scegliere come target workload specifici. Nel cluster deve essere in esecuzione un carico di lavoro, ad esempio un deployment Kubernetes, con etichette che possono corrispondere alle norme. Ad esempio, l'esempio httpbin è configurato per essere eseguito con l'etichetta app: httpbin. Puoi utilizzare la configurazione con httpbin e curl dalla guida Token JWT Istio.

Metodi per l'attivazione del recupero di JWKS

Esistono due modi principali per configurare Cloud Service Mesh in modo da consentire ai proxy Envoy di recuperare le chiavi JWKS da un jwksUri esterno:

Questo è l'approccio consigliato per la maggior parte degli scenari di produzione ed è obbligatorio per Cloud Service Mesh con MCP. Questo metodo ti offre il controllo esplicito su come la mesh interagisce con il fornitore JWKS esterno.

Definisci il servizio esterno con un ServiceEntry

Innanzitutto, devi creare un ServiceEntry Istio per fare in modo che il provider JWKS esterno sia un servizio noto all'interno della mesh. Questa risorsa consente la risoluzione DNS e il routing corretto per i proxy Envoy nel tuo data plane.

Per un criterio RequestAuthentication che utilizza jwksUri: "https://your-auth-provider.com/.well-known/jwks.json", devi creare il seguente 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

Configurare le impostazioni di connessione con un DestinationRule

In secondo luogo, potrebbe essere necessario un DestinationRule per specificare le impostazioni TLS lato client per le connessioni al fornitore JWKS, soprattutto se il fornitore richiede una configurazione TLS o mTLS specifica.

  • Per i provider che utilizzano certificati attendibili pubblicamente, crea un DestinationRule con tls.mode impostato su SIMPLE per attivare la convalida TLS standard lato server.
  • Per i provider che richiedono certificati client (mTLS), imposta tls.mode su MUTUAL e fornisci i percorsi ai certificati e alle chiavi che Envoy deve presentare.

Questo DestinationRule configura il criterio di connessione per ServiceEntry definito nel passaggio precedente:

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 queste risorse sono presenti e configurate correttamente, Envoy le utilizza per stabilire una connessione sicura e recuperare le chiavi JWKS.

2. Configurazione automatica di Cloud Service Mesh (solo Traffic Director)

Se Cloud Service Mesh non trova un ServiceEntry definito dall'utente che copre l'hostname e la porta di un jwksUri HTTPS in un criterio RequestAuthentication, configurerà automaticamente la configurazione necessaria per consentire a Envoy di recuperare le chiavi JWKS. Questa automazione semplifica la configurazione per gli scenari comuni in cui è sufficiente la connettività predefinita a jwksUri (HTTPS, TLS standard).

Condizioni per la configurazione automatica: questo comportamento automatico si applica se:

  • Stai utilizzando Cloud Service Mesh con Traffic Director.
  • jwksUri utilizza lo schema https.
  • jwksUri punta a un servizio esterno non locale del cluster.
  • Nessun visibile ServiceEntry (considerando lo spazio dei nomi del criterio RequestAuthentication e il campo exportTo di ServiceEntry) gestisce già l'hostname e la porta di jwksUri.

Se queste condizioni sono soddisfatte, i proxy Envoy verranno configurati per recuperare il JWKS senza richiedere la creazione di risorse ServiceEntry o DestinationRule esplicite per jwksUri.

Configurazione di RequestAuthentication

Indipendentemente dal metodo utilizzato per il recupero di JWKS, definisci le regole di convalida JWT utilizzando un criterio 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"

Campi chiave in jwtRules (per tutti i dettagli, consulta la documentazione di Istio RequestAuthentication):

  • issuer: l'emittente del JWT.
  • jwksUri: l'URI HTTPS del set di chiavi pubbliche (JWKS) del fornitore.
  • fromHeaders (facoltativo): specifica le posizioni delle intestazioni da cui è previsto il JWT.
  • fromParams (facoltativo): specifica i parametri di ricerca da cui è previsto il JWT.
  • forwardOriginalToken (Facoltativo): se è true, il token originale viene inoltrato al servizio upstream.

Applicazione dell'autenticazione JWT con AuthorizationPolicy

Per rifiutare le richieste prive di un JWT valido, devi associare le tue norme RequestAuthentication a un AuthorizationPolicy. Il seguente criterio consente le richieste al workload your-app solo se presentano un JWT valido dell'emittente e del soggetto specificati.

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

Per esempi e casi d'uso più dettagliati sull'utilizzo delle rivendicazioni JWT nell'autorizzazione, consulta l'attività di autorizzazione Istio per i token JWT.

Passaggi successivi