[Azure DataLake] Métodos para dar acceso
Hay muchos artículos que hablan sobre la creación de una plataforma unificada de datos, donde equipos de Analítica (bajo diferentes nombres) arman un data lake con ETLs y procesos de ingesta tomando datos de múltiples fuentes de información, almacenando y organizando datos para alimentar modelos de Business Intelligence, Data Science, Machine Learning, y otras ramas relacionadas de la analítica.
En este proceso de crecimiento, tanto en volumen como en fuentes de datos a considerar, siempre llega el momento en el que hay que compartir datos que tenemos en nuestro data lake con personas/equipos que desean usarlos y accederlos, externos al equipo que desarrollo la ingesta y transformación de datos. Este es un punto que muchos saben que eventualmente habrá que hacer, pero como no es vital al comienzo de un proyecto entonces se saltea (la conocida “deuda técnica”) y luego cuando aparece la necesidad, ¡estamos en un apuro por resolverlo! En este articulo voy a mostrar algunas de las opciones que tenemos para dar este tipo de permisos sin que esto sea un peligro para todo el trabajo que venimos realizando.
1- Azure Data Share
La primera opción que vamos a ver es Azure Data Share. Este recurso (distinto al data lake), nos va a permitir compartir snapshots de determinadas carpetas dentro de nuestro data lake. Esta opción es práctica pero tiene varias desventajas, la principal es que estamos replicando datos fuera de nuestro data lake (quien recibe el Data Share, debe mapear el snapshot a su propio data lake), esto da pie a que haya diferentes “versiones” de los datos y quien desee consultarlos no estará usando los datos actualizados, además de estar pagando por almacenamiento que no debería con otras opciones.
2- SFTP
¡La segunda opción que veremos es más directa que la anterior! El único requisito es que nuestro data lake debe tener activada la jerarquía de carpetas (Hierarchical Namespace en un Data lake Storage Gen2). Si tenemos eso deberíamos ver la opción en el portal para activar SFTP (preview por ahora). Esta opción nos permitirá levantar un servidor SFTP (ssh file transfer protocol) que leerá directamente desde nuestro data lake. La configuración es bastante sencilla, simplemente se crea un usuario (local al FTP, no será parte del Active Directory), se selecciona el contenedor que queremos compartir y los permisos (el mínimo sería READ y LIST). ¿Desventajas de este método? El permiso elegido en el FTP será independiente de la configuración de permisos RBAC, ABAC o ACLs que tengamos dispuesto en nuestro data lake, y los permisos rigen para todo el contenedor, no solo una carpeta. Otras desventajas son: esta opción no permite que el usuario lea directamente el data lake como otras opciones, y este servidor SFTP no es accesible por Data Factory (por ahora, ojalá cambie esto en un futuro).
Muchos clientes son capaces de conectarse a un servidor SFTP como si se tratase de una “carpeta remota” para descargar o subir archivos, de modo que es una opción practica para compartir datos con usuarios de todo tipo (negocio o técnicos). Los clientes clásicos para windows son WinSCP o FileZilla, pero ¡hay muchos más! (ni hablar para linux)
3- SAS
El tercer método que veremos para conectarnos es mediante un SAS (Shared Access Signature) y este sí que nos permitirá conectarnos y leer directamente el data lake desde cualquier software que pueda hacerlo (por ejemplo, código Python, desde Databricks, u otros servicios de Azure como Data Factory). Un SAS es básicamente una cadena de conexión, generada a partir de las Access Keys del lake, que permite que nos conectemos al data lake con determinados permisos que son elegidos al momento de crear esta SAS. Crear un SAS es muy sencillo, vamos a la opción homónima en el portal de Azure, elegimos que servicio deseamos habilitar (por lo general Blob), completamos las siguientes opciones según nuestras necesidades y finalmente damos click en Generar. La desventaja de este método es que los permisos que definamos valen para TODO el data lake, no solo para un contenedor o una carpeta, por lo que es fácil caer en dar demasiados permisos con este método. Arreglarlo es sencillo, ya que como los SAS son creados a partir de las Access Keys, renovando estas últimas todos los SAS que la utilizaron quedaran sin efecto.
Desde el explorer del lake, podemos generar SAS para una carpeta o archivo especifico, con lo que ganaremos mucho en seguridad sobre el método de creación de SAS anterior. Les dejo una imagen, no es para nada complicado, simplemente navegamos hasta la carpeta que queremos y damos click con el botón derecho:
Recordemos que los permisos mínimos para poder conectarnos y ver que archivos hay dentro de la carpeta son READ (obvio) y LIST. Este último es fácil de olvidar, pero si no lo agregamos el SAS podrá leer los archivos solo si le indicamos el nombre y la ruta exactos del archivo que queremos leer.
4- Service principal
El cuarto método que veremos para conectarnos es mediante un Service Principal. Esto es crear un usuario de servicio (App Registration) y luego asignarle los permisos necesarios para conectarse y leer el data lake. Este método es el recomendado por ser el más seguro de todos, ya que podemos definir los permisos de este usuario como lo haríamos con cualquier otro, mediante RBAC, ACL o el nuevo ABAC.
SPOILER: Si no sabes que significan estas siglas, atentos porque habrá un artículo sobre esto próximamente.
Básicamente, este método es el único mediante el cual tendremos un control más granular sobre los permisos que estamos dando dentro de nuestro data lake.
5- Autorizar usuario AD - ¡NO recomendada!
Este método es prácticamente igual al anterior, solo que en lugar de autorizar un Service Principal, lo haremos con un usuario de AD. La razón por la que no es recomendado hacer esto es porque no ofrece ninguna ventaja sobre hacerlo con un Service Principal y compartir sus credenciales (secret key o certificado). Además, como regla general y buena práctica, ningún proceso automatizado debería estar autenticándose con un usuario de AD.
Con esto concluye el artículo, por supuesto que ¡estas opciones no son todas las disponibles! Siempre hay muchas formas de lograr el mismo resultado, y decidí dejar afuera los requisitos específicos de algunos recursos como Synapse por ejemplo, que requiere que asignemos permisos RBAC al MSI del workspace, pero eso puede ser tema para otro post 😊
¡Espero que les sea de ayuda! Nos vemos en la próxima.
Escrito por Martin Zurita
0 notes
Digging this doc resource from Microsoft regarding the different types of service principals:
Application - The type of service principal is the local representation, or application instance, of a global application object in a single tenant or directory. In this case, a service principal is a concrete instance created from the application object and inherits certain properties from that application object. A service principal is created in each tenant where the application is used and references the globally unique app object. The service principal object defines what the app can actually do in the specific tenant, who can access the app, and what resources the app can access.
When an application is given permission to access resources in a tenant (upon registration or consent), a service principal object is created. When you register an application using the Azure portal, a service principal is created automatically. You can also create service principal objects in a tenant using Azure PowerShell, Azure CLI, Microsoft Graph, and other tools.
Managed identity - This type of service principal is used to represent a managed identity. Managed identities eliminate the need for developers to manage credentials. Managed identities provide an identity for applications to use when connecting to resources that support Azure AD authentication. When a managed identity is enabled, a service principal representing that managed identity is created in your tenant. Service principals representing managed identities can be granted access and permissions, but can't be updated or modified directly.
Legacy - This type of service principal represents a legacy app, which is an app created before app registrations were introduced or an app created through legacy experiences. A legacy service principal can have credentials, service principal names, reply URLs, and other properties that an authorized user can edit, but doesn't have an associated app registration. The service principal can only be used in the tenant where it was created.
0 notes
Day Sixty-Seven
Mr. B, Mr. I, and I met with The Principal, the Director of Student Services, and both Deans during PLC time this morning to discuss the way we currently track/level Global Studies and American Studies (I told the rest of the department they could join us, or do work on their own). Mr. B observed that students who aren't college-bound are being placed in college prep courses because there's no other option, and made the case that's not the best way to serve them or their college-bound peers. So we discussed possible changes we could make in the future, and obviously, that's going to take more than this one conversation, but I think we made a good start.
I spent my prep time checking over the essay outline assignment my Global Studies students had been doing; it's set up like a standard citation practice assignment (a set of questions to research, answer, and properly cite in MLA format), but this one had three, color-coded parts. Today, when my students came to class, I had them read the instructions and two examples of the Religion/Philosophy Essay, and some saw straight away how the work they'd done was going to set them up for essay drafting. The rest figured it out as we discussed the examples, and what was included in their introductions, bodies, and conclusions; I wrote discussion notes on the board in the same colors as the color-coding on the outline, and then it became totally clear.
For a lot of my students who're daunted by essay writing, realizing they'd already done the research and had it organized was a game-changer for their confidence. So I definitely think the way I sequenced these essay prep lessons- outline assignment, then instructions and examples, rather than the other way around (in which case a lot of students would have skipped the outlining, I think)- worked as intended. Feeling good about that!
APGOV was pretty excellent, too. We got into the Civil Rights Movement today by discussing Brown v. Board and subsequent school desegregation efforts, as well as the resistance to those efforts. A lot of my students knew about Ruby Bridges and the Little Rock Nine, a few knew about James Meredith, and it was good that they could bring their background knowledge into the conversation. After that, we tackled some things they new less about: the Federal Interstate Commerce Commission rule that interstate trains and buses- and station waiting rooms- had to be desegregated, Boynton v. Virginia, and the Freedom Rides. I showed an excerpt of PBS' Freedom Riders, which students found really engaging. It led into a great discussion.
And I had nothing to do at the end of the day, so I actually got to leave on time! Woohoo!
2 notes
·
View notes
President, um ?
All right. It is 1975 and the President is going to walk off the tarmac of Air Force One and meet the Little Archie gang. And which president is that?
Okay. I know the 2000 reprise looks enough like Bill Clinton -- I guess? - - But what's up with this Gerald Ford? Is this off of his modelling days?
Clinton as a bobblehead. Or one of those relay mascots in baseball games.
Well. We know the story can't follow with the last president.
Though, if Bill Clinton is politicking for votes to the Democratic ticket he may be barking up the wrong tree.
The story does have a reprint credit for 1982. I am guessing they stuck with the old model that looks not at all like Ford and even less like Reagan. But, Reagan did make a stopover a few years' later.
8 notes
·
View notes