Cómo crear un portal personalizado con SageMaker AI y MLflow integrado
Integrar MLflow en un portal interno permite a los equipos de ML acceder al tracking de experimentos mediante una única URL con SSO, sin presigned URLs ni acceso al AWS Console. Este artículo explica la arquitectura, el flujo de solicitudes y las consideraciones de seguridad para desplegar un frontend React con un proxy Flask que firma solicitudes con SigV4.
Resumen ejecutivo
A medida que los equipos de machine learning crecen, organizar el acceso al tracking de experimentos se vuelve un problema operativo. Distribuir presigned URLs no escala y dar acceso al AWS Management Console agrega carga administrativa. Una alternativa escalable es incrustar Amazon SageMaker AI MLflow Apps dentro de un portal personalizado integrado con SSO, de modo que los científicos de datos accedan con una sola autenticación y mediante una URL permanente.
En esta guía exploramos un patrón arquitectónico que combina un frontend React (con MLflow embebido en un iframe) y un proxy reverso en Flask que maneja la autenticación SigV4 con credenciales temporales. El resultado: una experiencia consistente para usuarios, menos fricción en la incorporación y control centralizado sobre accesos y auditoría.
Por qué conviene a equipos y organizaciones
- Experiencia unificada: los usuarios ingresan al portal corporativo y encuentran el tracking de experimentos junto a otras herramientas internas, sin manejar credenciales AWS.
- Escalabilidad operativa: evita la gestión manual de presigned URLs y reduce la necesidad de dar acceso directo al AWS Console.
- Integración con SSO: el portal puede integrarse con el proveedor de identidades de su organización, manteniendo políticas de acceso centralizadas.
- Automatización: pipelines CI/CD y scripts pueden llamar al mismo endpoint proxy; la firma SigV4 se hace detrás del proxy, simplificando la interacción programática con las APIs de MLflow.
Para equipos en América Latina, donde muchas organizaciones priorizan seguridad, cumplimiento y una experiencia de usuario centralizada, este enfoque facilita gobernanza y adopción al tiempo que respeta prácticas corporativas de identidad.
Arquitectura propuesta
La solución está compuesta por cuatro bloques principales:
-
Application Load Balancer (ALB)
- Punto de entrada único y estable para usuarios.
- Maneja terminación TLS/HTTPS (en producción se recomienda configurar un certificado con AWS Certificate Manager).
- Integra con DNS corporativo y políticas de acceso perimetral.
-
Frontend React (portal)
- Proporciona la interfaz de marca de la organización.
- Embebe la UI de MLflow en un iframe apuntando a una ruta proxy (por ejemplo /mlflow-ui/).
- Sirve archivos estáticos desde el proxy en la ruta /app.
-
Proxy reverso en Flask (ejecutándose en una instancia EC2)
- Intercepta todas las solicitudes del navegador dirigidas a MLflow (páginas y llamadas a las APIs REST).
- Obtiene credenciales temporales asumiendo un role IAM dedicado y firma cada solicitud con AWS Signature Version 4 (SigV4).
- Reescribe URLs absolutas en las respuestas HTML para que la navegación funcione a través del proxy.
- Elimina encabezados como X-Frame-Options que impedirían renderizar MLflow dentro del iframe.
-
Amazon SageMaker AI MLflow Apps
- Backend fully managed que provee tracking de experimentos, métricas, parámetros, artefactos y un registro de modelos.
- No requiere mantener servidores ni parcheos; el proxy traduce las llamadas HTTPS a peticiones autenticadas hacia este servicio.
Flujo de solicitudes (cómo funciona para el usuario)
- El usuario abre la URL del portal (ALB) desde el navegador o desde el portal interno.
- El ALB enruta la petición hacia la instancia EC2 que ejecuta el proxy Flask.
- El proxy sirve la aplicación React desde /app. El React carga la UI de MLflow dentro de un iframe apuntando a /mlflow-ui/.
- Todas las solicitudes generadas por el iframe (carga de páginas y llamadas a /api/2.0/mlflow/…) pasan por el proxy.
- El proxy asume el role IAM dedicado, firma cada petición con SigV4 y la reenvía al endpoint de MLflow Apps gestionado por SageMaker AI.
- En las respuestas, el proxy adapta enlaces absolutos a rutas relativas y elimina restricciones de frame para permitir el renderizado dentro del iframe.
- El usuario ve la UI completa de MLflow con autenticación y permisos gestionados centralmente.
Ventajas operativas y de seguridad
- Centralización de identidad: al integrar el portal con SSO, los equipos usan sus credenciales corporativas y los administradores mantienen control sobre el acceso.
- Menor sobrecarga administrativa: no es necesario emitir o rotar presigned URLs por cada usuario o sesión.
- Aislamiento de credenciales AWS: los usuarios finales no manipulan claves; el proxy controla la interacción con AWS mediante roles y credenciales temporales.
- Compatibilidad con automatización: las mismas rutas proxy pueden ser consumidas por pipelines, facilitando integración CI/CD.
Consideraciones de seguridad y buenas prácticas
- Usar HTTPS en ALB con certificados gestionados (ACM) para proteger tráfico y cookies.
- Aplicar el principio de least privilege en el role IAM que asume el proxy: limitar permisos al mínimo necesario para MLflow Apps.
- Registrar y monitorear accesos y llamadas (CloudWatch, registros del proxy, auditoría de IAM) para cumplimiento y trazabilidad.
- Asegurar la instancia EC2 que ejecuta el proxy: parches, grupos de seguridad restringidos, y políticas de acceso administrativo controladas.
- Revisar las políticas de contenido y encabezados (CSP, X-Frame-Options) para mantener un equilibrio entre seguridad y la necesidad de renderizar en iframe.
Despliegue y validación (pasos generales)
El patrón se puede desplegar mediante infraestructura como código (por ejemplo, AWS CDK). A alto nivel los pasos incluyen:
- Provisionar ALB con configuración de listeners y reglas que enrutuen tráfico a la instancia del proxy.
- Desplegar la instancia EC2 con el proxy Flask y el rol IAM asociado.
- Construir y desplegar la aplicación React que sirve el iframe y los activos estáticos.
- Configurar el role que el proxy asumirá para firmar solicitudes hacia SageMaker AI MLflow Apps.
- Validar que la aplicación React muestra la UI de MLflow y que las llamadas API pasan por el proxy y reciben respuestas correctas.
No se requieren credenciales de usuario AWS en los navegadores: la autenticación entre el proxy y SageMaker AI queda encapsulada en el backend.
Consideraciones para equipos en América Latina
Para organizaciones latinoamericanas con requisitos regulatorios o políticas internas de seguridad, este patrón facilita integrar MLflow dentro de flujos de identidad corporativos (SSO) y controles de auditoría. Además, al evitar compartir accesos directos al console y centralizar la firma SigV4 en un proxy controlado, se reduce el riesgo operativo y se acelera la adopción por equipos distribuidos.
Conclusión
Incrustar Amazon SageMaker AI MLflow Apps en un portal SSO mediante un frontend React y un proxy Flask que maneja SigV4 ofrece una solución escalable, segura y práctica para equipos de datos. Simplifica la gestión de accesos, mejora la experiencia de usuario y mantiene compatibilidad con pipelines automatizados. Para producción, prioricen HTTPS, roles de mínimo privilegio, monitoreo y revisiones periódicas de seguridad.
Fuente original: AWS ML Blog