JWT-Authentifizierung mit Remote-JWKS konfigurieren

Mit Cloud Service Mesh können Sie Ihre Dienste schützen, indem Sie JSON Web Tokens (JWT) mit der benutzerdefinierten Istio-Ressource RequestAuthentication validieren. Ein wichtiger Teil dieser Konfiguration ist das Feld jwksUri, das den URI des JWKS-Anbieters (JSON Web Key Set) angibt. Dieser JWKS enthält die öffentlichen Schlüssel, die zum Validieren eingehender JWTs verwendet werden.

Wichtig: In Cloud Service Mesh ist die Datenebene (Envoy-Proxys) dafür verantwortlich, die JWKS-Schlüssel direkt von jwksUri abzurufen. Die Cloud Service Mesh-Steuerungsebene (verwaltet von Traffic Director) führt keine externen Aufrufe aus, um diese Schlüssel abzurufen. Das bedeutet, dass die gesamte Netzwerkkommunikation mit externen JWKS-Anbietern vom Envoy-Proxy Ihrer Arbeitslast ausgeht.

Voraussetzungen für den externen JWKS-Zugriff

Für diese Anleitung benötigen Sie Folgendes:

  • Organisationsrichtlinie für den Internetzugriff: Wenn Ihr jwksUri auf einen externen Internetendpunkt verweist, muss Ihre Google Cloud -Organisationsrichtlinie ausgehenden Internetzugriff von Ihren Arbeitslasten zulassen. Prüfen Sie insbesondere, ob die Organisationsrichtlinie constraints/compute.disableInternetNetworkEndpointGroup nicht erzwungen wird. Wenn diese Richtlinie aktiviert ist, schlägt das Abrufen von JWKS von externen jwksUri fehl.

  • Eine mit Labels versehene Kubernetes-Arbeitslast: Die Ressourcen RequestAuthentication und AuthorizationPolicy verwenden ein selector, um bestimmte Arbeitslasten anzusprechen. In Ihrem Cluster muss eine Arbeitslast wie eine Kubernetes-Bereitstellung mit Labels ausgeführt werden, die mit den Richtlinien übereinstimmen können. Das Beispiel httpbin ist beispielsweise für die Ausführung mit dem Label app: httpbin konfiguriert. Sie können die Einrichtung mit httpbin und curl aus der Anleitung für Istio-JWT-Tokens verwenden.

Methoden zum Aktivieren des JWKS-Abrufs

Es gibt zwei Hauptmethoden, um Cloud Service Mesh so zu konfigurieren, dass Ihre Envoy-Proxys JWKS-Schlüssel von einem externen jwksUri abrufen können:

Dies ist der empfohlene Ansatz für die meisten Produktionsszenarien und er ist für Cloud Service Mesh mit MCP erforderlich. Mit dieser Methode haben Sie die explizite Kontrolle darüber, wie Ihr Mesh mit dem externen JWKS-Anbieter interagiert.

Externen Dienst mit einer ServiceEntry definieren

Zuerst müssen Sie ein Istio-ServiceEntry erstellen, damit der externe JWKS-Anbieter ein bekannter Dienst in Ihrem Mesh ist. Diese Ressource ermöglicht die DNS-Auflösung und das richtige Routing für die Envoy-Proxys in Ihrer Datenebene.

Für eine RequestAuthentication-Richtlinie, die jwksUri: "https://your-auth-provider.com/.well-known/jwks.json" verwendet, erstellen Sie die folgende 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

Verbindungseinstellungen mit einem DestinationRule konfigurieren

Zweitens benötigen Sie möglicherweise ein DestinationRule, um clientseitige TLS-Einstellungen für Verbindungen zum JWKS-Anbieter anzugeben, insbesondere wenn der Anbieter eine bestimmte TLS- oder mTLS-Konfiguration erfordert.

  • Für Anbieter, die öffentlich vertrauenswürdige Zertifikate verwenden: Erstellen Sie ein DestinationRule mit tls.mode auf SIMPLE, um die standardmäßige serverseitige TLS-Validierung zu aktivieren.
  • Für Anbieter, die Clientzertifikate (mTLS) erfordern: Setzen Sie tls.mode auf MUTUAL und geben Sie die Pfade zu den Zertifikaten und Schlüsseln an, die Envoy präsentieren muss.

Mit diesem DestinationRule wird die Verbindungsrichtlinie für die im vorherigen Schritt definierte ServiceEntry konfiguriert:

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

Wenn diese Ressourcen vorhanden und richtig konfiguriert sind, verwendet Envoy sie, um eine sichere Verbindung herzustellen und die JWKS-Schlüssel abzurufen.

2. Automatisierte Konfiguration durch Cloud Service Mesh (nur Traffic Director)

Wenn Cloud Service Mesh keine benutzerdefinierte ServiceEntry findet, die den Hostnamen und Port eines HTTPS-jwksUri in einer RequestAuthentication-Richtlinie abdeckt, wird die erforderliche Einrichtung für Envoy automatisch konfiguriert, um die JWKS-Schlüssel abzurufen. Diese Automatisierung vereinfacht die Einrichtung für gängige Szenarien, in denen die Standardverbindung zu jwksUri (HTTPS, Standard-TLS) ausreicht.

Bedingungen für die automatische Konfiguration: Dieses automatisierte Verhalten gilt, wenn:

  • Sie verwenden Cloud Service Mesh mit Traffic Director.
  • Für jwksUri wird das Schema https verwendet.
  • jwksUri verweist auf einen externen Dienst, der nicht clusterlokal ist.
  • Kein sichtbares ServiceEntry (unter Berücksichtigung des Namespace der RequestAuthentication-Richtlinie und des Felds exportTo des ServiceEntry) verwaltet bereits den Hostnamen und Port des jwksUri.

Wenn diese Bedingungen erfüllt sind, werden Ihre Envoy-Proxys so konfiguriert, dass die JWKS abgerufen werden, ohne dass Sie explizite ServiceEntry- oder DestinationRule-Ressourcen für diesen jwksUri erstellen müssen.

RequestAuthentication wird konfiguriert

Unabhängig von der Methode, die zum Abrufen von JWKS verwendet wird, definieren Sie JWT-Validierungsregeln mit einer RequestAuthentication-Richtlinie.

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"

Wichtige Felder in jwtRules (vollständige Informationen finden Sie in der Istio-Dokumentation zu RequestAuthentication):

  • issuer: Der Aussteller des JWT.
  • jwksUri: Der HTTPS-URI des öffentlichen Schlüsselsets (JWKS) des Anbieters.
  • fromHeaders (Optional): Gibt die Header-Speicherorte an, an denen das JWT erwartet wird.
  • fromParams (Optional): Gibt Abfrageparameter an, aus denen das JWT erwartet wird.
  • forwardOriginalToken (optional): Wenn „true“, wird das ursprüngliche Token an den Upstream-Dienst weitergeleitet.

JWT-Authentifizierung mit AuthorizationPolicy erzwingen

Wenn Sie Anfragen ohne gültiges JWT ablehnen möchten, müssen Sie Ihre RequestAuthentication-Richtlinie mit einer AuthorizationPolicy kombinieren. Die folgende Richtlinie lässt Anfragen an den your-app-Workload nur zu, wenn sie ein gültiges JWT vom angegebenen Aussteller und Subjekt enthalten.

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

Detailliertere Beispiele und Anwendungsfälle für die Verwendung von JWT-Ansprüchen in der Autorisierung finden Sie in der Istio-Aufgabe zur Autorisierung für JWT-Tokens.

Weitere Informationen