Siempre hay un detalle que puede complicar un proyecto de ingeniería de datos, especialmente cuando tenemos que trabajar con APIs limitadas o hay políticas de seguridad que requieren que los datos viajen por canales seguros.
En este artículo te mostramos como podemos acceder desde Fabric Notebooks a un origen de API por un canal seguro e IP pública única.
Si hay algo en lo que estamos de acuerdo es que conectarse a una API compleja siempre será más robusto y flexible hacerlo por código. Si estamos en Fabric, probablemente elijamos usar notebooks por sobre Pipelines. Los Pipelines están buenísimos, pero si de creación dinámica de token o jwt trata, se puede complicar.
Normalmente, cuando necesitamos canalizar Fabric por un canal seguro podemos usar la nueva feature de VNet Gateway. Sin embargo, ese canal solo funciona para los ítems Dataflow Gen2, Fabric data pipelines, Fabric Copy Job, Fabric Mirroring, Power BI semantic models y Power BI paginated reports. Fabric pensé que siempre necesitaríamos obtener datos desde esos ítems. Nosotros sabemos que obtener datos desde Notebooks puede ocurrir y quedamos frenados.
Para requerimientos de canales de seguridad dedicados por redes privadas, no podríamos ir por esa vía.
Por otro lado, algunos orígenes podrían dejarnos cargar las IPs públicas anunciadas por Microsoft sobre sus servicios. Lametablemente, no siempre es así. Fabric Notebooks puede salir por powerbi o por azure cloud. Lo que genera aproximadamente 150 rangos de IP y más de 600 mil IPs públicas. La carga de estas excepciones es inviable para algunos orígenes de datos.
¿Cómo podemos entonces salir a conectarnos en canal único y seguro? La realidad es que hoy no se puede 100% porque eso requeriría que Fabric Notebooks tengan configuraciones de redes privadas. A modo de alternativa, podemos canalizar que Fabric acceda a otro recurso que si esta configurado en una red. En este ejemplo tenemos una API de acceso restringido a 10 IPs públicas. Para que Fabric Notebooks pueda llegar, necesitaremos ayuda de otros recursos de azure. Primero un proxy que garantice una IP pública única. Segundo una red de privada de comunicación. Tercero un puente que ejecute las llamadas a la API y Fabric pueda comunicarse. La solución sería como muestra la siguiente imagen:
- Azure NAT Gateway: es un servicio de traducción de direcciones de red (NAT) totalmente administrado y altamente resistente. Use Azure NAT Gateway para permitir que todas las instancias de una subred se conecten de salida a Internet mientras permanecen completamente privadas
- Virtual Networks: permite a los recursos de Azure, como máquinas virtuales (VM) comunicarse de forma segura entre sí, Internet y redes locales
- Azure Functions: es una solución sin servidor que le permite crear aplicaciones sólidas mientras usa menos código y con menos infraestructura y menores costos. En lugar de preocuparse de implementar y mantener servidores, puede usar la infraestructura en la nube para proporcionar todos los recursos actualizados necesarios para mantener sus aplicaciones en funcionamiento
Comenzamos creando una red virtual y en su configuración una subred:
Luego se asociará el NAT. También vamos a ir a Delegaciones para delegar a la subred el servicio de Apps de Azure:
Ahora creamos un Azure NAT Gateway asegurándonos que en Outbound IP creemos una IP pública. La clave aquí será asociar la red antes creada en networking:
La asociación debería asignarle a la red la salida nat automáticamente. Podemos validarlo buscando nuestra red y chequeando sus opciones:
Ahora si podemos continuar con nuestra Azure function. Lo primero será saber que solo los planes premium, app service flex consumption van a permitir la salida por red virtual. En nuestro caso iremos por flex consumption porque sabemos que el consumo será bastante reducido. Lo importante aquí es la sección de networking para seleccionar nuestra red virtual y su subred:
Por defecto, solo el tráfico hacia IPs privadas va por la VNet. Para que el tráfico hacia internet (tu API externa) use el NAT Gateway, debes configurar la aplicación para que todo el tráfico salga por la red virtual.
Esto lo vamos a configurar desde el azure functions. Buscamos el menú de configuración y las variables de entorno para configurar la siguiente:
WEBSITE_VNET_ROUTE_ALL = 1
El aplicar reiniciará la Function App para que tome efecto.
No vamos a explicar como se hace una Azure Function. Para ello puede leer la documentación de Microsoft. Pero si podemos mostrar que para probar podemos hacer un muy simple ejemplo con Python que tiene el siguiente código:
A la derecha tenemos los requests para llamar a la API de Azure Functions y el código solo hace un request a la api de ipify que devuelve la ip que la está consultando.
Podemos probarlo ejecutando un request de la azure function super sencillo para ver que la IP que devuelve:
Así comprobamos que coincide con nuestra IP generada en nuestro NAT Gateway:
De este modo hemos generado un túnel para que nuestro Fabric Notebook viajen a buscar datos por una red virtual controlada y segura que sale por una IP única. ¿Podríamos haber usado otro recurso en lugar de azure functions? Si. Podríamos usar Azure Logic Apps o código en un App Service Plan. Elegí functions por su free tier y familiaridad de uso. Además, que sería más práctico tener ahí una función que genere los requests de forma genérica los llamemos desde un notebook.
Espero que les haya servido para conocer un poco más sobre redes, seguridad y obtener datos con Fabric notebooks.