Los clientes empresariales tienen múltiples líneas de negocios (LOB) y grupos y equipos dentro de ellos. Estos clientes necesitan equilibrar la gobernanza, la seguridad y el cumplimiento con la necesidad de que los equipos de aprendizaje automático (ML) accedan rápidamente a sus entornos de ciencia de datos de manera segura. Estos clientes empresariales que están comenzando a adoptar AWS, expandiendo su huella en AWS o planeando mejorar un entorno de AWS establecido necesitan asegurarse de tener una base sólida para su entorno de nube. Un aspecto importante de esta base es organizar su entorno de AWS siguiendo una estrategia de múltiples cuentas.

En el post Proteja las URL prefirmadas de Amazon SageMaker Studio Parte 2: API privada con autenticación JWT, demostramos cómo construir una API privada para generar Estudio Amazon SageMaker URL prefirmadas a las que solo puede acceder un usuario final autenticado dentro de la red corporativa desde una sola cuenta. En esta publicación, mostramos cómo puede extender esa arquitectura a múltiples cuentas para admitir múltiples LOB. Demostramos cómo puede usar URL prefirmadas de Studio en un entorno de múltiples cuentas para asegurar y enrutar el acceso de diferentes personas a su dominio de Studio apropiado. Explicamos el proceso y el flujo de la red, y cómo escalar fácilmente esta arquitectura a múltiples cuentas y Amazon SageMaker dominios La solución propuesta también garantiza que todo el tráfico de la red permanezca dentro de la red privada de AWS y que la comunicación se realice de forma segura.

Aunque demostramos el uso de dos LOB diferentes, cada uno con una cuenta de AWS independiente, esta solución se puede escalar a varios LOB. También presentamos una construcción lógica de una cuenta de servicios compartidos que desempeña un papel clave en el gobierno, la administración y la orquestación.

Resumen de la solución

Podemos lograr la comunicación entre las VPC de SageMaker de todas las LOB y la VPC de la cuenta de servicios compartidos mediante interconexión de VPC o Pasarela de tránsito de AWS. En esta publicación, usamos una puerta de enlace de tránsito porque proporciona un mecanismo de comunicación de VPC a VPC más simple que la interconexión de VPC cuando hay una gran cantidad de VPC involucradas. También usamos Ruta del Amazonas 53 reglas de reenvío en combinación con resoluciones entrantes y salientes para resolver todas las consultas de DNS a los puntos finales de la VPC de la cuenta de servicio compartido. La arquitectura de red se ha diseñado utilizando los siguientes patrones:

Veamos los dos componentes principales de la arquitectura, el flujo de información y el flujo de red, con más detalle.

Flujo de información

El siguiente diagrama ilustra la arquitectura del flujo de información.

Los pasos del flujo de trabajo son los siguientes:

1. El usuario se autentica con el Cognito Amazonas grupo de usuarios y recibe un token para consumir la API de acceso de Studio.
2. El usuario llama a la API para acceder a Studio e incluye el token en la solicitud.
3. Cuando se invoca esta API, la costumbre AWS Lambda El autorizador se activa para validar el token con el proveedor de identidad (IdP) y devuelve los permisos adecuados para el usuario.
4. Una vez que se autoriza la llamada, se activa una función de Lambda.
5. Esta función de Lambda utiliza el nombre del usuario para recuperar su nombre de LOB y la cuenta de LOB de los siguientes Amazon DynamoDB tablas que almacenan estas relaciones:
   1. Tabla de usuarios – Esta tabla contiene la relación entre los usuarios y su LOB.
   2. tabla de LOB – Esta tabla contiene la relación entre los LOB y la cuenta de AWS donde existe el dominio de SageMaker para ese LOB.
6. Con el ID de cuenta, la función Lambda asume el rol PresignedUrlGenerator en esa cuenta (cada cuenta LOB tiene un rol PresignedURLGenerator que solo puede asumir la función Lambda encargada de generar las URL prefirmadas).
7. Finalmente, la función invoca la llamada a la API create-presigned-domain-url de SageMaker para ese usuario en su dominio SageMaker de LOB.
8. La URL prefirmada se devuelve al usuario final, quien la consume a través del punto final de la VPC de Studio.

Los pasos 1 a 4 se tratan con más detalle en Parte 2 de esta serie, donde explicamos cómo funciona el autorizador Lambda personalizado y se encarga del proceso de autorización en la API Gateway de acceso.

Flujo de red

Todo el tráfico de la red fluye de forma segura y privada utilizando Enlace privado de AWS, como se muestra en el siguiente diagrama.

Los pasos son los siguientes:

1. Cuando el usuario llama a la API de acceso, ocurre a través del punto de enlace de la VPC para Puerta de enlace API de Amazon en la red VPC en la cuenta de servicios compartidos. Esta API está configurada como privada y tiene una política que permite su consumo solo a través de este punto de enlace de la VPC, como se describe en Parte 2 de esta serie
2. Todo el proceso de autorización ocurre de forma privada entre API Gateway, Lambda y Amazon Cognito.
3. Una vez que se otorga la autorización, API Gateway activa la función Lambda a cargo de generar las URL prefirmadas utilizando la red privada de AWS.
4. Luego, debido a que la función Lambda de enrutamiento reside en una VPC, todas las llamadas a diferentes servicios se realizan a través de sus respectivos puntos de enlace de la VPC en la cuenta de servicios compartidos. La función realiza las siguientes acciones:
   1. Recupere las credenciales para asumir el rol a través de la Servicio de token de seguridad de AWS (AWS STS) Punto de enlace de la VPC en la cuenta de red.
   2. Llame a DynamoDB para recuperar información de usuario y LOB a través del punto de enlace de la VPC de DynamoDB.
   3. Llame a la API de SageMaker para crear una URL prefirmada para el usuario en su dominio de SageMaker a través del punto final de la VPC de la API de SageMaker.
5. El usuario finalmente consume la URL prefirmada a través del punto de enlace de la VPC de Studio en la VPC de red en la cuenta de servicios compartidos, porque este punto de enlace de la VPC se especificó durante la creación de la URL prefirmada.
6. Todas las demás comunicaciones entre Studio y los servicios de AWS se realizan a través de ENI de Studio dentro de la VPC de SageMaker de la cuenta LOB. Por ejemplo, para permitir que SageMaker llame Registro de contenedores elásticos de Amazon (Amazon ECR), el punto de enlace de la VPC de la interfaz de Amazon ECR se puede aprovisionar en la VPC de la cuenta de servicios compartidos y se comparte una regla de reenvío con las cuentas de SageMaker que necesitan consumirla. Esto permite que las consultas de SageMaker a Amazon ECR se resuelvan en este punto final, y el enrutamiento de Transit Gateway hará el resto.

Requisitos previos

Para representar un entorno de múltiples cuentas, usamos una cuenta de servicios compartidos y dos LOB diferentes:

• cuenta de servicios compartidos – Dónde viven los puntos de enlace de la VPC y la API de Gateway de acceso de Studio
• Cuenta de SageMaker LOB A – La cuenta para el dominio de SageMaker para LOB A
• Cuenta de SageMaker LOB B – La cuenta para el dominio de SageMaker para LOB B

Para obtener más información sobre cómo crear una cuenta de AWS, consulte ¿Cómo creo y activo una nueva cuenta de AWS?.

Las cuentas LOB son entidades lógicas que son específicas del negocio, departamento o dominio. Asumimos una cuenta por entidad lógica. Sin embargo, habrá diferentes cuentas por entorno (desarrollo, prueba, producción). Para cada entorno, normalmente tiene una cuenta de servicios compartidos separada (según los requisitos de cumplimiento) para restringir el radio de explosión.

Puede usar las plantillas e instrucciones en el Repositorio GitHub para instalar la infraestructura necesaria. Este repositorio está estructurado en carpetas para las diferentes cuentas y diferentes partes de la solución.

configuración de la infraestructura

Para las grandes empresas con muchos dominios de Studio, también es recomendable tener una arquitectura de punto final centralizada. Esto puede generar ahorros de costos a medida que la arquitectura escala y se crean más dominios y cuentas. La plantilla networking.yml en la cuenta de servicios compartidos implementa los puntos de enlace de la VPC y los recursos necesarios de Route 53, y la infraestructura de Transit Gateway para escalar la solución propuesta.

Las instrucciones detalladas de la implementación se pueden encontrar en el archivo README.md en el repositorio de GitHub. La implementación completa incluye los siguientes recursos:

• Dos Formación en la nube de AWS plantillas en la cuenta de servicios compartidos: una para la infraestructura de red y otra para la Modelo de aplicación sin servidor de AWS (AWS SAM) API de puerta de enlace de acceso a Studio
• Una plantilla de CloudFormation para la infraestructura en la cuenta SageMaker LOB A
• Una plantilla de CloudFormation para la infraestructura de la cuenta SageMaker LOB B
• Opcionalmente, se puede implementar un simulador local en la cuenta de servicios compartidos para probar la implementación de un extremo a otro.

Después de implementar todo, vaya a la consola de Transit Gateway para cada cuenta de SageMaker (cuentas LOB) y confirme que Transit Gateway se haya compartido correctamente y que las VPC estén asociadas a ella.

Opcionalmente, si se han compartido reglas de reenvío con las cuentas, se pueden asociar con la VPC de las cuentas de SageMaker. Las reglas básicas para que la solución de puntos de enlace de la VPC centralizada funcione se comparten automáticamente con la cuenta LOB durante la implementación. Para obtener más información sobre este enfoque, consulte Acceso centralizado a puntos finales privados de VPC.

Rellenar los datos

Ejecute el siguiente script para completar las tablas de DynamoDB y el grupo de usuarios de Amazon Cognito con la información necesaria:

./scripts/setup/fill-data.sh

El script realiza las llamadas a la API requeridas usando el Interfaz de línea de comandos de AWS (AWS CLI) y los parámetros y perfiles previamente configurados.

Usuarios de Amazon Cognito

Este paso funciona igual que Parte 2 de esta serie, pero debe realizarse para los usuarios en todas las LOB y debe coincidir con su perfil de usuario en SageMaker, independientemente de la LOB a la que pertenezcan. Para esta publicación, tenemos un usuario en un dominio de Studio en LOB A (user-lob-a) y un usuario en un dominio de Studio en LOB B (user-lob-b). La siguiente tabla enumera los usuarios incluidos en el grupo de usuarios de Amazon Cognito.

Tenga en cuenta que estas contraseñas se han configurado con fines de demostración.

Tablas de DynamoDB

La aplicación de acceso utiliza dos tablas de DynamoDB para dirigir las solicitudes de los diferentes usuarios al dominio de Studio de su LOB.

La tabla de usuarios contiene la relación entre los usuarios y su LOB.

La tabla LOB contiene la relación entre el LOB y la cuenta de AWS donde existe el dominio de SageMaker para ese LOB.

Tenga en cuenta que estos nombres de usuario deben ser coherentes entre los perfiles de usuario de Studio y los nombres de los usuarios que agregamos previamente al grupo de usuarios de Amazon Cognito.

Probar la implementación

En este punto, podemos probar la implementación yendo a API Gateway y verificar qué responde la API para cualquiera de los usuarios. Obtenemos una URL preestablecida en la respuesta; sin embargo, consumir esa URL en el navegador generará un error de token de autenticación.

Para esta demostración, configuramos un entorno local simulado con un host bastión y una aplicación de Windows. Instalamos Firefox en la instancia de Windows y usamos las herramientas de desarrollo para agregar encabezados de autorización a nuestras solicitudes y probar la solución. Hay disponible información más detallada sobre cómo configurar el entorno simulado local en el repositorio de GitHub asociado.

El siguiente diagrama muestra nuestra arquitectura de prueba.

Tenemos dos usuarios, uno para LOB A (Usuario A) y otro para LOB B (Usuario B), y mostramos cómo cambia el dominio de Studio simplemente cambiando la clave de autorización recuperada de Amazon Cognito al iniciar sesión como Usuario A y Usuario B.

Complete los siguientes pasos para probar la implementación:

1. Recupere el token de sesión para el Usuario A, como se muestra en Parte 2 de la serie y también en las instrucciones del repositorio de GitHub.

Usamos el siguiente comando de ejemplo para obtener las credenciales de usuario de Amazon Cognito:

aws cognito-idp initiate-auth --auth-flow USER_PASSWORD_AUTH --client-id <your-cognito-client-id> --auth-parameters USERNAME=user-lob-a,PASSWORD=Userloba1! --region <your-region>

2. Para esta demostración, usamos una aplicación local de Windows simulada. Para conectarse a la instancia de Windows, puede seguir el mismo enfoque especificado en Acceso seguro a Amazon SageMaker Studio con AWS SSO y una aplicación SAML.
3. Firefox debe estar instalado en la instancia. Si no, una vez en la instancia, podemos instalar Firefox.
4. Abra Firefox e intente acceder a la API de Studio con user-lob-a or user-lob-b como el parámetro de ruta de la API.

Recibe un mensaje de no autorizado.

5. Abra las herramientas de desarrollo de Firefox y en el Nuestra red pestaña, elija (haga clic con el botón derecho) la llamada API anterior y elija Editar y reenviar.

6. Aquí agregamos el token como un encabezado de autorización en las herramientas de desarrollo de Firefox y hacemos la solicitud a Studio access Gateway API nuevamente.

Esta vez, vemos en las herramientas para desarrolladores que la URL se devuelve junto con una redirección 302.

7. Aunque la redirección no funcionará cuando utilice las herramientas de desarrollo, aún puede elegirla para acceder al dominio LOB SageMaker para ese usuario.

8. Repita para el Usuario B con su token correspondiente y verifique que sea redirigido a un dominio de Studio diferente.

Si realiza estos pasos correctamente, puede acceder a ambos dominios al mismo tiempo.

En nuestra aplicación local de Windows, podemos consumir ambos dominios a través del punto final de Studio VPC a través de nuestra conexión de interconexión de VPC.

Exploremos algunos otros escenarios de prueba.

Si vuelve a editar la API y cambia la ruta al LOB opuesto, al reenviar, obtenemos un error en la respuesta de la API: una respuesta prohibida de API Gateway.

Intentar tomar la URL devuelta para el usuario correcto y consumirla en el navegador de su computadora portátil también fallará, ya que no se consumirá a través del punto final interno de la VPC de Studio. Este es el mismo error que vimos cuando probamos con API Gateway. Devuelve un error de "Token de autenticación que contiene permisos insuficientes".

Si tarda demasiado en consumir la URL prefirmada, se producirá un error de "Token de autenticación no válido o caducado".

Escalar dominios

Cada vez que se agrega un nuevo dominio de SageMaker, debe completar los siguientes pasos de acceso y redes:

1. Comparta la puerta de enlace de tránsito con la nueva cuenta usando Administrador de acceso a recursos de AWS (RAM de AWS).
2. Adjunte la VPC a la puerta de enlace de tránsito en la cuenta LOB (esto se hace en AWS CloudFormation).

En nuestro escenario, la puerta de enlace de tránsito se configuró con asociación automática a la tabla de rutas predeterminada y la propagación automática habilitada. En un caso de uso del mundo real, es posible que deba completar tres pasos adicionales:

3. En la cuenta de servicios compartidos, asocie la VPC de Studio adjunta a la tabla de rutas de Transit Gateway respectiva para los dominios de SageMaker.
4. Propaga las rutas de VPC asociadas a Transit Gateway.
5. Por último, agregue el ID de cuenta junto con el nombre de LOB a la tabla de DynamoDB de LOB.

Limpiar

Complete los siguientes pasos para limpiar sus recursos:

1. Elimine la interconexión de VPC.
2. Elimine las VPC asociadas de las zonas hospedadas privadas.
3. Elimine la plantilla del simulador local de la cuenta de servicios compartidos.
4. Elimine las plantillas de Studio CloudFormation de las cuentas de SageMaker.
5. Elimine la plantilla de CloudFormation de acceso de la cuenta de servicios compartidos.
6. Elimine la plantilla de red de CloudFormation de la cuenta de servicios compartidos.

Conclusión

En esta publicación, explicamos cómo puede configurar el acceso a la API privada de varias cuentas para Studio. Explicamos cómo se producen los flujos de redes y aplicaciones, así como también cómo puede escalar fácilmente esta arquitectura para varias cuentas y dominios de SageMaker. Dirígete a la Repositorio GitHub para comenzar tu viaje. ¡Nos encantaría escuchar sus comentarios!

Acerca de los autores

neelam koshiya es arquitecto de soluciones empresariales en AWS. Su enfoque actual es ayudar a los clientes empresariales con su viaje de adopción de la nube para obtener resultados comerciales estratégicos. En su tiempo libre, le gusta leer y estar al aire libre.

Alberto Menéndez es consultor asociado de DevOps en servicios profesionales en AWS. Ayuda a acelerar los viajes de los clientes a la nube. En su tiempo libre le gusta practicar deportes, especialmente baloncesto y pádel, pasar tiempo con su familia y amigos y aprender sobre tecnología.

Rajesh Ramchander es ingeniero sénior de datos y aprendizaje automático en servicios profesionales en AWS. Ayuda a los clientes a migrar cargas de trabajo de big data y AL/ML a AWS.

carnero vital es arquitecto de soluciones de aprendizaje automático en AWS. Tiene más de 20 años de experiencia en la arquitectura y creación de aplicaciones distribuidas, híbridas y en la nube. Le apasiona crear soluciones seguras y escalables de AI/ML y big data para ayudar a los clientes empresariales con su proceso de optimización y adopción de la nube para mejorar sus resultados comerciales. En su tiempo libre, disfruta del tenis y la fotografía.

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. Accede Aquí.
• Acuñando el futuro con Adryenn Ashley. Accede Aquí.
• Fuente: https://aws.amazon.com/blogs/machine-learning/secure-amazon-sagemaker-studio-presigned-urls-part-3-multi-account-private-api-access-to-studio/