Configura la autenticación de JWT con JWKS remotos

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

Importante: En Cloud Service Mesh, el plano de datos (proxies de Envoy) es responsable de recuperar las claves de JWKS directamente desde jwksUri. El plano de control de Cloud Service Mesh (administrado por Traffic Director) no realiza llamadas externas para recuperar estas claves. Esto significa que toda la comunicación de red con los proveedores externos de JWKS se origina en el proxy de Envoy de tu carga de trabajo.

Requisitos previos para el acceso externo a JWKS

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 extremo externo de Internet, la política de tu organización Google Cloud debe permitir el acceso saliente a Internet desde tus cargas de trabajo. Específicamente, verifica que la política de la organización constraints/compute.disableInternetNetworkEndpointGroup no se aplique. Si se habilita esta política, fallará la recuperación de JWKS desde jwksUri externos.

  • Una carga de trabajo de Kubernetes etiquetada: Los recursos RequestAuthentication y AuthorizationPolicy usan un selector para segmentar cargas de trabajo específicas. Debes tener una carga de trabajo, como una implementación de Kubernetes, que se ejecute en tu clúster con etiquetas que las políticas puedan hacer coincidir. 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 de JWT de Istio.

Métodos para habilitar la recuperación de JWKS

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

Este es el enfoque recomendado para la mayoría de las situaciones de producción y es obligatorio para Cloud Service Mesh con MCP. Este método te brinda un control explícito sobre cómo tu malla interactúa con el proveedor externo de JWKS.

Define el servicio externo con un ServiceEntry

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

Para una política de RequestAuthentication que usa 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

Configura los parámetros de conexión con un DestinationRule

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

  • Para los proveedores que usan certificados de confianza pública, crea un DestinationRule con tls.mode establecido en SIMPLE para habilitar la validación estándar de TLS del servidor.
  • Para los proveedores que requieren certificados de cliente (mTLS), establece tls.mode en MUTUAL y proporciona las rutas de acceso a los certificados y las claves que debe presentar Envoy.

Este DestinationRule configura la política de conexión para el 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

Cómo controlar el tráfico de aplicaciones hacia el mismo proveedor de JWKS

En algunos casos, es posible que tu aplicación necesite comunicarse directamente con el mismo servicio externo que proporciona el jwksUri. Por ejemplo, es posible que tu aplicación necesite llamar a un extremo de autenticación en your-auth-provider.com mientras Cloud Service Mesh recupera las claves de JWKS del mismo host.

Si sigues la configuración estándar de DestinationRule con tls: mode: SIMPLE, todo el tráfico de tu malla a your-auth-provider.com tendrá TLS originado por el proxy de Envoy. Si tu aplicación también origina TLS para sus solicitudes al mismo host, esto puede generar errores de conexión para el tráfico de la aplicación debido a un problema de encriptación de "doble TLS".

Para resolver este problema, puedes usar un DestinationRule con subconjuntos para aplicar diferentes políticas de TLS para la recuperación de JWKS y para el tráfico de la aplicación.

  1. Crea un ServiceEntry como lo harías normalmente:

    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

  2. Crea un DestinationRule con una política de tráfico para las recuperaciones de JWKS y un subconjunto para el tráfico de la aplicación:

    • El valor predeterminado trafficPolicy habilita el iniciación de TLS para las recuperaciones de JWKS de Cloud Service Mesh.
    • Un subset con nombre (p.ej., app-traffic) inhabilita el iniciación de TLS de Cloud Service Mesh, lo que permite que la aplicación controle TLS por sí misma.
    apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: "external-jwks-provider-dr"
  namespace: your-namespace
spec:
  host: "your-auth-provider.com"
  trafficPolicy:
    tls:
      mode: SIMPLE
  subsets:
  - name: app-traffic
    trafficPolicy:
      tls:
        # Use DISABLE to prevent Envoy from originating TLS for the application's traffic
        mode: DISABLE

  3. Crea un VirtualService para enrutar el tráfico de la aplicación al subconjunto adecuado: Este VirtualService garantiza que el tráfico de tu aplicación al host externo se envíe al subconjunto app-traffic, que omite el iniciación de TLS de Cloud Service Mesh.

    apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: "route-for-app-to-jwks-provider"
  namespace: your-namespace # The namespace of your application
spec:
  hosts:
  - "your-auth-provider.com"
  http:
  - route:
    - destination:
        host: "your-auth-provider.com"
        subset: app-traffic

Con esta configuración, puedes recuperar de forma segura las claves de JWKS para la autenticación de JWT y, al mismo tiempo, permitir que tu aplicación se comunique directamente con el mismo proveedor externo sin conflictos.

2. Configuración automatizada por 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 de RequestAuthentication, configurará automáticamente la configuración necesaria para que Envoy recupere las claves de JWKS. Esta automatización simplifica la configuración para situaciones comunes en las que la conectividad predeterminada a jwksUri (HTTPS, TLS estándar) es suficiente.

Condiciones para la configuración automática: Este comportamiento automático se aplica en los siguientes casos:

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

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

Configurando RequestAuthentication

Independientemente del método que se use para recuperar el JWKS, definirás las reglas de validación de JWT con 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 en jwtRules (consulta la documentación de Istio RequestAuthentication para obtener todos los detalles):

  • issuer: Es la entidad emisora del JWT.
  • jwksUri: Es 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 desde los que se espera el JWT.
  • forwardOriginalToken (opcional): Si es verdadero, el token original se reenvía al servicio upstream.

Cómo aplicar la autenticación de JWT con AuthorizationPolicy

Para rechazar las solicitudes que no tienen un JWT válido, debes vincular 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 obtener ejemplos y casos de uso 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 de JWT.

Pasos siguientes