Una de las muchas características que proporciona Istio es la posibilidad de autenticar de forma centralizada a los usuarios finales que tratan de acceder a la malla de servicios, liberando a los aplicativos de la necesidad de implementar dicha funcionalidad.
En el presente documento se pretende detallar la configuración de Istio necesaria para validar la autenticación contra Azure Active Directory, el popular servicio de administración de identidad y acceso basado en la nube de Microsoft.
Caso de uso
Se dispone de un cluster de Kubernetes, con Istio instalado, en él se encuentra un microservicio al que se le quiere aplicar una política de autenticación contra un Azure Active Directory ya creado.
Se da por hecho que se conoce el procedimiento para obtener el JWT a través de la API proporcionada por Microsoft. De igual manera, se adjunta un enlace a la documentación oficial en el que se describe el proceso en detalle.
Istio End User Authentication
Actualmente la política de autenticación de Istio únicamente permite validar aquellas credenciales presentadas en formato JWT (JSON Web Token) que sigan el estándar OpenID.
Dicho esto, es hora de crear la política de autenticación para el microservicio “my-app”.
apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
name: auth-policy
namespace: lab
spec:
targets:
- name: my-app
origins:
- jwt:
issuer: "https://sts.windows.net/{tenant}/"
jwksUri: "https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys"
trigger_rules:
- excluded_paths:
- exact: /health
- exact: /metrics
principalBinding: USE_ORIGIN
La configuración es exactamente la misma a la especificada en documentación oficial, a excepción del issuer y el jwksUrl, los cuales varían en función del proveedor de autenticación. En el caso de Azure AD, los valores son siempre los mismos y se diferencian en base al tenant, el id que representa a su organización.
Se puede encontrar el tenant accediendo al centro de administración de Azure Active Directory, en la sección de propiedades. Se mostrará el valor el cuadro “Directory ID”.
Adicionalmente se han excluido los endpoints “/health” y “/metrics” para no causar conflictos ni a Prometheus ni a los “health checks” de Kubernetes.
Origin authentication failed
Es posible que aun habiendo proporcionado un JWT valido, Istio devuelva un código HTTP 401 con el mensaje “Origin authentication failed”. En ese caso lo recomendable es consultar los logs del istio-proxy para determinar el origen del problema, pero muy probablemente se deba a un error con validación de la firma (JWT_INVALID_SIGNATURE error).
En caso de utilizar un scope asociado a un servicio se Microshoft, como por ejemplo, “https://graph.microsoft.com/*** “, el JWT contendrá un campo “nonce” como cabecera requerido para la verificación de la firma, con el objetivo de mitigar los ataques de repiticion de token.
Por desgracia, esta característica no está soportada por Istio, por lo que será necesario asociar o crear un scope distinto para la aplicación registrada en el Azure AD, para que el token no contenga dicho campo.
Conclusiones
En conclusión, configurar Istio para validar la autenticación contra Azure Active Directory es relativamente sencillo, si bien también puede ser frustrante dar con la configuración acertada, por lo que se recomienda leer con atención tanto la documentación oficial como los pasos descritos en el presente artículo.
Mikel's TechBlog 