Configurar la autenticación JWT con JWKS remoto

Cloud Service Mesh te permite proteger tus servicios validando tokens web JSON (JWT) mediante el recurso personalizado RequestAuthentication de Istio. Una parte fundamental de esta configuración es el campo jwksUri, que especifica el URI del proveedor del conjunto de claves web de JSON (JWKS). Este JWKS contiene las claves públicas que se usan para validar los JWTs entrantes.

Importante: En Cloud Service Mesh, el plano de datos (proxies de Envoy) es el responsable de obtener las claves JWKS directamente del jwksUri. El plano de control de Cloud Service Mesh (gestionado por Traffic Director) no hace llamadas externas para obtener estas claves. Esto significa que toda la comunicación de red con proveedores de JWKS externos procede del proxy Envoy de tu carga de trabajo.

Requisitos previos para el acceso a JWKS externo

Para seguir esta guía, necesitas lo siguiente:

  • Política de la organización para el acceso a Internet: si tu jwksUri apunta a un endpoint de Internet externo, la política de tu organización Google Cloud debe permitir el acceso a Internet saliente desde tus cargas de trabajo. En concreto, comprueba que la política de la organización constraints/compute.disableInternetNetworkEndpointGroup no esté aplicada. Si se habilita esta política, no se podrán obtener JWKS de jwksUris externos.

  • Carga de trabajo de Kubernetes etiquetada: los recursos RequestAuthentication y AuthorizationPolicy usan un selector para orientarse a cargas de trabajo específicas. Debes tener una carga de trabajo, como un deployment de Kubernetes, ejecutándose en tu clúster con etiquetas que coincidan con las políticas. Por ejemplo, la muestra httpbin está configurada para ejecutarse con la etiqueta app: httpbin. Puedes usar la configuración con httpbin y curl de la guía Token JWT de Istio.

Métodos para habilitar la obtención de JWKS

Hay dos formas principales de configurar Cloud Service Mesh para permitir que tus proxies de Envoy obtengan claves JWKS de un jwksUri externo:

Este es el enfoque recomendado para la mayoría de los casos prácticos de producción y es obligatorio para Cloud Service Mesh con MCP. Este método te permite controlar explícitamente cómo interactúa tu malla con el proveedor de JWKS externo.

Define el servicio externo con un ServiceEntry.

Primero, debes crear un ServiceEntry de Istio para que el proveedor de JWKS externo sea un servicio conocido en tu malla. Este recurso permite la resolución de DNS y el enrutamiento adecuado de los proxies de Envoy en tu plano de datos.

En el caso de una política RequestAuthentication que use jwksUri: "https://your-auth-provider.com/.well-known/jwks.json", crearías el siguiente 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 los ajustes de conexión con un DestinationRule

En segundo lugar, es posible que necesites un DestinationRule para especificar la configuración de TLS del lado del cliente para las conexiones con el proveedor de JWKS, sobre todo si el proveedor requiere una configuración específica de TLS o mTLS.

  • En el caso de los proveedores que usen certificados de confianza pública, crea un DestinationRule con tls.mode definido como SIMPLE para habilitar la validación TLS estándar del lado del servidor.
  • En el caso de los proveedores que requieren certificados de cliente (mTLS), asigna el valor MUTUAL a tls.mode y proporciona las rutas a los certificados y las claves que debe presentar Envoy.

Este DestinationRule configura la política de conexión del ServiceEntry definido en el paso 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

Cuando estos recursos están presentes y configurados correctamente, Envoy los usa para establecer una conexión segura y obtener las claves JWKS.

2. Configuración automatizada mediante Cloud Service Mesh (solo Traffic Director)

Si Cloud Service Mesh no encuentra un ServiceEntry definido por el usuario que cubra el nombre de host y el puerto de un jwksUri HTTPS en una política RequestAuthentication, configurará automáticamente la configuración necesaria para que Envoy obtenga las claves JWKS. Esta automatización simplifica la configuración en los casos habituales en los que es suficiente la conectividad predeterminada a jwksUri (HTTPS, TLS estándar).

Condiciones para la configuración automática: este comportamiento automático se aplica si:

  • Estás usando Cloud Service Mesh con Traffic Director.
  • jwksUri usa el esquema https.
  • El jwksUri apunta a un servicio externo que no es local del clúster.
  • Ningún visible ServiceEntry (teniendo en cuenta el espacio de nombres de la política RequestAuthentication y el campo exportTo de ServiceEntry) ya gestiona el nombre de host y el puerto de jwksUri.

Si se cumplen estas condiciones, tus proxies de Envoy se configurarán para obtener el JWKS sin que tengas que crear recursos ServiceEntry o DestinationRule explícitos para ese jwksUri.

Configurar RequestAuthentication

Independientemente del método que se utilice para obtener JWKS, las reglas de validación de JWT se definen mediante una 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 clave de jwtRules (consulta la documentación de Istio RequestAuthentication para obtener información detallada):

  • issuer: la entidad emisora del JWT.
  • jwksUri: el URI HTTPS del conjunto de claves públicas (JWKS) del proveedor.
  • fromHeaders (Opcional): especifica las ubicaciones de los encabezados desde los que se espera el JWT.
  • fromParams (Opcional): especifica los parámetros de consulta de los que se espera el JWT.
  • forwardOriginalToken (Opcional): si es true, el token original se reenvía al servicio upstream.

Implementación obligatoria de la autenticación JWT con AuthorizationPolicy

Para rechazar las solicitudes que no tengan un JWT válido, debes emparejar tu política RequestAuthentication con un AuthorizationPolicy. La siguiente política permite solicitudes a la carga de trabajo your-app solo si presentan un JWT válido del emisor y el asunto 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 ejemplos y casos prácticos más detallados sobre el uso de las reclamaciones de JWT en la autorización, consulta la tarea de autorización de Istio para tokens JWT.

Siguientes pasos