AWS Lake Formation es un servicio que AWS puso en funcionamiento el 8 de agosto de 2019. El objetivo de este servicio era el de facilitar el gobierno y la seguridad del acceso al dato de forma centralizada, permitiendo la compartición segura de datos desde y hacia los distintos servicios de almacenamiento, análisis y ML de AWS.

estructura de AWS lake formation

La habilidad fundamental de este servicio, a modo de resumen, consiste en asignar permisos a los recursos disponibles en AWS Glue Data Catalog mediante roles, usando un formato muy parecido a los “grants” de las bases de datos de toda la vida. Dichos permisos pueden ser a nivel de base de datos, tabla, columna, fila y celda, lo que permite una gran granularidad. El catálogo de datos de AWS Glue, centraliza la administración y gestión de los datos, pero también puede hacer de conector con otros catálogos de, por ejemplo, un metastore de Hive. Asimismo, se integra con otros servicios de AWS como Amazon Athena, AWS Glue, Amazon Redshift Spectrum y Amazon EMR que pueden usar Lake Formation para acceder a los datos de S3 registrados en el catálogo.

Al tratarse de un servicio de AWS, se integra perfectamente con AWS IAM para la autenticación usuarios y roles para el acceso a los datos, pero también dispone de otros tipos de integraciones con otras herramientas de gobierno o motores como son Starbust, Dremio, Privacera y Collibra.

Por otro lado, gracias a las funcionalidades de cross-account y cross-region, se pueden compartir los datos de forma segura aunque estén distribuidos entre múltiples cuentas, organizaciones y regiones de AWS. Esta funcionalidad facilita la creación de arquitecturas de datos más modernas tipo Data Mesh, sin necesidad de tener que tener todos los datos en un mismo lugar y, por lo tanto, ahorrando mucho trasiego de los datos hacia ese lugar centralizado.

aws, starbust, privacera, dremio, collibra

Otra funcionalidad muy útil de Lake Formation es la capacidad de escalar en esa gestión de permisos. En la actualidad, el crecimiento en el volumen de datos, productos de datos y necesidades de compartir de forma segura y ordenada dichos productos crea una necesidad en las grandes organizaciones de disponer una forma segura de facilitar el escalado en la asignación de estos permisos. Gracias a Lake Formation y los permisos basados en tags, el administrador puede asignar LF-Tags a los recursos de un catálogo de datos y dar permisos a los usuarios / aplicaciones sobre los recursos que tienen dichos LF-Tags. Los LF-tags pueden gestionarse de forma dinámica usando servicios como AWS Glue Sensitive Data Detection, de forma que pueda identificar datos sensibles y tagear en consecuencia cierto recurso de un catálogo de datos.

Por otro lado, AWS Lake Formation se integra con AWS Data Exchange para encontrar, suscribirte y utilizar datos de terceros en la nube, así como compartir tus productos de datos con negocios externos sin necesidad de moverlos o copiarlos.

Uno de los objetivos de Lake Formation es permitir a los usuarios tener un mayor conocimiento de los datos que tienen en su catálogo de AWS Glue. Así pues, la conjunción de ambos servicios permite la búsqueda por nombre, contenido, datos sensibles o cualquier otra etiqueta personalizada definida en los recursos del catálogo.

Por último, Lake Formation permite acceder a los logs de auditoría a través de Amazon CloudTrail. Esto facilita mucho la auditoría de los accesos a los datos, pues se puede visualizar rápidamente qué usuarios o roles han intentado acceder a qué datos y en qué momento.

Llegados a este punto, es evidente que Lake Formation es un pilar fundamental para cualquier plataforma de datos en AWS que necesite segregación de acceso al catálogo de datos de Glue. Pero ¿cómo de bueno es Lake Formation? ¿De verdad cumple todo lo que promete? ¿Tiene sentido que sea únicamente a través de Glue (con el coste asociado que supone) la exposición de dichos accesos? A continuación profundizaremos en lo que consideramos, desde la experiencia, que son sus fortalezas y debilidades.

Lo bueno, lo malo, y nuestra lista de deseos para el futuro de Lake Formation

Después de llevar esta tecnología a producción, pensamos que Lake Formation tiene mucho potencial pero también que tiene mucho campo de mejora en algunos aspectos. En este artículo, queremos compartir algunos de los retos que hemos encontrado al implementar esta segregación de datos en empresas grandes con más de 100 cuentas AWS y más de 100 TB en S3. Por cada reto explicaremos soluciones alternativas y funcionalidades que nos gustaría encontrar en futuras versiones. Con un poco de suerte, AWS ya habrá implementado soluciones nativas incluso antes de que podáis leer este artículo. De lo contrario, os invitamos a probar los caminos alternativos que hemos probado.

Otras maneras de consumir los datos

Como ya hemos comentado, Lake Formation permite controlar el acceso a los datos a través de servicios como Athena y Glue. El problema es que existen algunos flujos intensivos, como el entrenamiento de modelos de machine learning en los que es preferible el acceso directo a S3, o combinar llamadas al catálogo de Glue con llamadas a S3. Estas dos opciones son más rápidas y más baratas que el procesamiento a través de Athena. Actualmente, Lake Formation no facilita una segregación sencilla del acceso directo por S3. En este caso, nuestras alternativas complementarias a Lake Formation fueron las siguientes:

1 ABAC (Attribute-based access control)

Es un método que consiste en decorar los Principals (usuarios, grupos, roles) con tags IAM como si fueran llaves-etiquetas. Por otro lado, hay que definir políticas de accesos sobre los recursos que hacen referencia a estos tags de Principals, como si fueran cerraduras. Solo se permiten unas acciones de un Principal sobre un recurso si el principal tiene un tag esperado.

Esta solución tiene el problema de que no llega al nivel extremo de granularidad de LF que consigue limitar por filas y por columnas de tablas. Sin embargo, las limitaciones ABAC por prefijos en S3 de unidad de negocio, proyecto, base de datos, tablas, y particiones generalmente, suelen ser más que suficiente para cubrir las necesidades del departamento de negocio.

Un ejemplo de configuración ABAC bastante habitual:

Suponemos un bucket de datos críticos con un segundo nivel de prefijos organizados por squad de desarrollo. Por debajo de estos prefijos, cada squad habrá montado sus bases de datos, tablas, y otros experimentos. Decidimos que solo se dará acceso a datos bajo un prefijo para los usuarios o procesos que pertenecen al squad.

Ejemplo ABAC por squads

Parece fácil, suponiendo 4 prefijos de squad, una decena de herederos colaborativos, y dos temporadas. Pero imaginemos ahora que el proyecto tiene muchísimo éxito. Salen más temporadas, precuelas, secuelas, spin-off, remakes… Ahora nos toca aterrizar unas reglas de herencias cruzadas de 100+ personas, sobre 10+ prefijos, dentro de un único JSON para una Bucket policy limitada a 20 KB.

De esta situación, solo el ABAC, nos puede salvar:

Por un lado, decoramos cada Role de usuario o de proceso con los tags IAM de squad que les corresponden, con la opción de heredar de varios squads. Por otro lado, en la Bucket Policy, hay que definir reglas de acceso cortas y flexibles usando variables de tags como “${aws:PrincipalTag/Got:squad_member}”. Con este método, podemos escalar independientemente del éxito del proyecto. Podríamos hasta imaginar que la asignación de tags a Principals sea basada en grupos AD o que la segregación de uso se extiende a otros recursos críticos o costosos de AWS.

2 S3 Access Points

Los puntos de accesos S3 se podrían ver como buckets virtuales o vistas sobre un prefijo de un bucket real. Tienen sus propios nombres que podemos usar para acciones de lectura y escritura, casi como si fueran nombres de buckets clásicos.

Antes teníamos que definir todas las asignaciones de permisos cross–accounts en un JSON complejo, creando un elemento innecesariamente crítico. La alternativa actual es crear un Access Point S3 por cada unidad de negocio o proyecto, lo que permite una atribución de los accesos por S3 más flexible y ordenada. Cada Access Point S3 tiene su propia política de acceso específica al proyecto.

Visibilidad sobre los permisos existentes

Es cierto que Lake Formation permite ver los permisos de cada recurso, pero lo cierto es que la verificación de la segregación requiere que una persona de operaciones liste cada uno de los múltiples accesos otorgados por nuestro sistema. Ya sea para hacer una auditoría, listar los permisos de una persona, o listar las personas con acceso a un recurso específico (database, tabla, entrada, columna). No es muy intuitivo ni fácil de usar: la consola de AWS no propone criterios de búsqueda básicos como un campo por el valor de un tag, por ejemplo. Además, en el caso de un Data Mesh, la información está distribuida en varias cuentas.

La solución propuesta en este caso fue la de tener un proceso ejecutado desde una lambda o Notebook local para extraer estos permisos usando boto3. Eso nos permitió versionar la información en S3 y analizarla con toda la potencia de filtros y de agregación que tienen Excel y Pandas.

Un regalo estupendo de AWS sería mejorar los campos de búsqueda de permisos LF y/o permitir un botón de exportación sencilla, que facilita mucho la vida de los administradores en este aspecto.

Infraestructura por código

En los dos años que llevamos con Lake Formation, hemos visto una mejora sustancial en el soporte de AWS Cloudformation y Hashicorp Terraform para los recursos relacionados con Lake Formation. No obstante, aún recomiendo la manipulación de los tags LF y sus permisos usando un código con boto3 detrás de un recursos custom Cloudformation o de un AWS Service Catalogue. Esto os puede evitar sorpresas de reemplazo de recurso. El reemplazo de un permiso es una operación que puede provocar un nivel de estrés equivalente a tener que quitar y volver a poner todas las cerraduras y llaves de un banco en medio de una release.

Una herramienta amiga que contenga toda esta potencia

Lake Formation es una herramienta maravillosa y súper potente para especialistas en data y seguridad. Nos ahorra manipular por código custom a las RAM, bucket policy, Glue Settings, KMS… Pero ciertamente no es una herramienta muy atractiva para un perfil de negocio, ni siquiera para data scientist. Las personas de negocio o data scientists no quieren tener que lidiar con algo tan técnico o complejo. Se levantan por la mañana con otros objetivos en la vida. Necesitan un nivel de abstracción que permita gestionar sus productos de datos como si fueran unos de los recursos más valiosos de la empresa y sin complejidad.

AWS propone el servicio Datazone para funcionalidades como catálogo de datos, descubrimiento automático de catálogo por ML, gestionando de manera fácil y rápida los accesos. Datazone está integrado con Lake Formation, Redshift, Atenea, Glue.

Desafortunadamente, cuando vimos las demos, todavía no disponía de funcionalidades esenciales como una integración suficiente con roles IAM. Esto fue bloqueante porque muchas empresas necesitan los roles SSO para la gestión de usuarios por grupos AD centralizados.

Sin embargo, recomiendo vigilar las actualizaciones del servicio Datazone. Tiene mucho potencial por su integración nativa con el ecosistema AWS y por los conceptos intuitivos que aportan al objetivo data mesh.

En definitiva, Lake Formation tiene sus pros y sus contras, lo que no quita que se haya convertido en el eje fundamental para el gobierno y gestión del dato en la mayor parte de las arquitecturas de datos que se despliegan hoy en día sobre AWS.

Cuéntanos qué te parece.

Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.

Suscríbete