Soy parte del equipo de Kyma responsable de los temas de exposición de API. Mi equipo y yo trabajamos para brindar una manera conveniente, confiable y segura de exponer las cargas de trabajo. En esta publicación de blog, me gustaría compartir nuestro plan para rediseñar APIRule CR y explicar cómo la nueva versión afecta los componentes que respaldan API Gateway.

Fondo

El componente API Gateway es un controlador de Kubernetes responsable de observar APIRule CR y crear los subrecursos necesarios para exponer y asegurar una carga de trabajo. El controlador API Gateway utiliza Istio VirtualService y la regla Oathkeeper de ORY bajo el capó. A partir de la pila ORY de Kyma 2.2, Hydra y Oathkeeper están obsoletos, y los CR de Istio proporcionarán las funcionalidades equivalentes. La nueva solución basada en Istio mejorará la estabilidad y la confiabilidad de una carga de trabajo expuesta y simplificará la arquitectura de API Gateway.

La arquitectura actual utiliza VirtualService y Rule CR. Por lo tanto, el componente API Gateway tiene dependencias tanto con el componente Istio como con el componente OATHkeeper de ORY. Si el propietario de una carga de trabajo decide proteger su carga de trabajo mediante el cliente OAuth2, también se debe crear la dependencia del servidor ORY Hydra OAuth2.

El siguiente gráfico muestra el flujo de exposición y protección de una carga de trabajo. Veamos cómo se usa cada dependencia. Cuando el usuario implementa su carga de trabajo y quiere exponerla y protegerla, crea Istio Gateway CR y procede a crear APIRule CR, que es procesada por el controlador de API Gateway. El controlador de API Gateway crea Istio VirtualService para exponer una carga de trabajo y la regla OATHkeeper de ORY para asegurar la carga de trabajo. Según los requisitos, es posible que el usuario que desee acceder a la carga de trabajo deba emitir un token. Pueden utilizar un token opaco ORY Hydra o un proveedor compatible con JWT OIDC, por ejemplo, SAP Cloud Identity Services – Identity Authentication. ORY Hydra OAuth2Client CR y las credenciales utilizadas para emitir un token de ORY Hydra deben crearse. Finalmente, se puede acceder a la carga de trabajo mediante el token. Para conocer las mejores prácticas de JWT, lea esta entrada de blog.

Cuando el usuario envía una solicitud con el token a la carga de trabajo, la solicitud llega primero a Istio Ingress Gateway. Istio Ingress Gateway reenvía esta solicitud al componente OATHkeeper de ORY, un proxy inverso responsable de autorizar las solicitudes entrantes. ORY Oathkeeper comprueba las reglas existentes. Cuando encuentra una regla coincidente, valida y autoriza la solicitud. La solicitud autorizada correctamente se reenvía a la carga de trabajo.

¿A donde nos dirigimos?

Nuestro objetivo es proporcionar un componente que permita a los usuarios exponer sus cargas de trabajo de manera confiable y segura. La investigación que realizamos sobre las soluciones disponibles nos convenció de que es hora de separarse de la pila ORY y comenzar a utilizar Istio, el componente que Kyma ya proporciona. La implementación del controlador APIRule JWT basada en la regla Oauthkeeper de ORY se reemplazará con la implementación basada en los CR de AuthorizationPolicy y RequestAuthentication de Istio. La implementación del controlador APIRule OAuth2 se reemplazará con la funcionalidad de autorización externa de Istio utilizando el componente oauth2-proxy.

El siguiente diagrama muestra el controlador API Gateway, que crea los recursos relacionados con Istio. El usuario crea una aplicación utilizando el proveedor compatible con OICD de su elección, configurado por el administrador en el componente oauth2-proxy que forma parte del autorizador externo de Istio.

En el futuro, Istio Ingress Gateway será responsable de la autorización en el flujo JWT. Validará el token con la configuración definida en RequestAuthentication CR y autorizará la solicitud como se describe en AuthorizationPolicy CR. Si está permitido, la solicitud se reenviará a la carga de trabajo.

Aprovechar Istio nos ahorra un salto al componente adicional y hace que el procesamiento de solicitudes sea más rápido. Al eliminar ORY Oathkeeper, simplificamos la complejidad y mejoramos la estabilidad del componente API Gateway. Agregar el proxy oauth2 administrado por el componente Kyma Istio facilitará la exposición y protección de Kiali, Grafana y Jaeger y permitirá su uso en el escenario OAuth2 con API Gateway.

¿Cómo llegamos allí?

Mejorar la arquitectura de las funcionalidades de exposición de API requiere algunos cambios profundos. Tenemos previsto introducir los cambios por fases para reducir el riesgo que puedan conllevar. Apoyaremos y guiaremos a nuestros clientes en cada paso del proceso. Estamos trabajando activamente en la implementación alternativa del controlador APIRule JWT basado en los CR de AuthorizationPolicy y RequestAuthentication de Istio. Consideramos las mejores prácticas de JWT en el lado del verificador de tokens e identificamos los cambios importantes. Nuestro objetivo es lanzar esta implementación lo antes posible para que los usuarios puedan comenzar a probarla lo antes posible y podamos recopilar comentarios y solicitudes de funciones. Los cambios se publicarán como una función disponible para los usuarios que deseen participar en la adopción anticipada. Paralelamente, estamos trabajando en alternativas para el componente ORY Hydra, al que seguirán los cambios en los controladores APIRule OAuth2. Todas las mejoras estarán respaldadas con procedimientos y scripts de migración.

Resumen

El dominio de exposición de API está sujeto a algunos cambios arquitectónicos significativos y consecuentes, que se publicarán junto con actualizaciones de funcionalidad y estabilidad. Esta publicación de blog es la primera de una serie en la que explico el futuro del componente API Gateway y APIRule CR. Suscribirse a SAP BTP, blogs en tiempo de ejecución de Kyma para estar al día. En caso de que tenga alguna inquietud o comentario, déjanos una pregunta.