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 de forma forzosa. 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 Istio JWT Token.

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 habilita 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), configura tls.mode como MUTUAL y proporciona las rutas de acceso a los certificados y las claves que Envoy debe presentar.

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

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

2. Configuración automatizada con 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