Control de acceso Snowflake a escala

Cada vez son más las empresas que sitúan a Snowflake en el centro de su data platforms. Aunque se trate de una solución gestionada, sigue siendo necesario administrar el entorno. Puede ser un reto, especialmente para las grandes empresas.

Uno de los retos es control de acceso. Es una pieza crítica de cualquier programa data governance. Snowflake proporciona funciones listas para usar para ayudar a afrontar este reto. Pero cuando tiene docenas de usuarios y terabytes de data, las funciones integradas no son suficientes. Necesita pensar en una estrategia para gestionar su cuenta.

Hemos estado allí. Por una de nuestros clientes, gestionamos una cuenta con más de 50 usuarios activos. Diseñamos una solución para escalar la gestión del control de acceso.

Este artículo describirá los principales aprendizajes del año pasado.

Antes de incorporarnos a la empresa, la cuenta ya estaba creada y se habían puesto en práctica muchas buenas ideas. Funciones personalizadas se habían creado. Los usuarios se gestionaban cuidadosamente. Pero había algunas limitaciones:

Creamos un nuevo sistema para gestionar el control de acceso y luchar contra esas deficiencias.

En primer lugar, revocamos todas las concesiones de roles por defecto (SYSADMIN, USERADMIN...) a los usuarios... Sólo unas pocas personas pudieron asumir esos roles. Eran los responsables de la administración.

En segundo lugar, creamos un marco de control de acceso basado en roles personalizados. Definimos dos tipos de roles personalizados:

Optamos por definir las funciones de acceso en el datanivel básico. Facilita la replicación de los privilegios de un entorno a otro mediante la clonación de copia cero. También compensación entre la flexibilidad que concedemos a los usuarios finales y la aplicación estricta del principio del menor privilegio.

En el nivel database, definimos 3 niveles de roles de acceso:

Aplicamos una estrategia similar al acceso al almacén con dos tipos de roles:

A continuación se muestra una ilustración de nuestro marco. Las flechas representan subvenciones.

En este punto, teníamos una mejor idea de cómo gestionaríamos los permisos, pero también teníamos problemas con la gestión de usuarios.

Establecimos Inicio de sesión único para permitir a los usuarios de Snowflake inicie sesión a través de Azure Active Directory (AAD). Así, eliminamos la complejidad de mantener dos databases de usuarios y el proceso de baja fue más robusto. En efecto, sólo tuvimos que dar de baja al usuario en AAD y la supresión se replicó automáticamente en Snowflake.

Como existe un mapeo entre los grupos AD y los roles en Snowflake, pudimos conceder un rol a cada usuario que creamos. Seguimos el mismo proceso para cada nuevo usuario.

Es el proceso para usuarios humanos reales, pero no aborda una de las limitaciones mencionadas al principio de este artículo: el uso de credenciales personales para trabajos automatizados.

Por eso hemos introducido cuentas de servicio. La gestión de las cuentas de servicio es muy similar a la que acabamos de describir. La única diferencia es que creamos un rol funcional para cada cuenta de servicio. Existe un relación uno a uno entre las cuentas de servicio y sus funciones. Así, limitamos estrictamente el alcance de los permisos para cada cuenta de servicio.

Esos pasos supusieron grandes mejoras. Todo estaba documentado. Los equipos adoptaron rápidamente el nuevo marco. Estábamos contentos.

Pero seguíamos dedicando mucho tiempo a conceder acceso manualmente y, al ser muy manual, también era propenso a errores. La necesidad de una herramienta que automatizara esas tareas era evidente.

Teníamos varias opciones:

Finalmente creamos un CLI en Python.

Preferimos utilizar Terraform para desplegar infraestructura y sólo infraestructura. Pueden producirse comportamientos no deseados cuando empiece a gestionar sus usuarios y sus permisos con terraform. Por ejemplo, la rotación de secretos es muy difícil de gestionar.

Nos gusta bash pero sólo para operaciones ad-hoc y sencillas. Aquí necesitamos cargar archivos de configuración, interactuar con la API Snowflake y manipular estructuras data. Esto es posible pero sería difícil de mantener a largo plazo.

Además de este aspecto, necesitábamos fiabilidad. Una forma de conseguirlo es escribir pruebas. Esto es más fácil de hacer en lenguajes de programación como Python.

Cuando ejecute la herramienta, esto es lo que ocurre entre bastidores.

Por diseño, la herramienta no crea un rol que ya existe. Lo mismo ocurre con los privilegios. La herramienta calcula el diferencia entre la configuración y el entorno remoto y aplica los cambios necesarios. Esto nos permite evitar cualquier tiempo de inactividad.

Inicialmente ejecutamos esta herramienta de forma local. Pero esto podía dar lugar a problemas. Por ejemplo, podíamos tener conflictos entre dos ingenieros que intentaban hacer cambios al mismo tiempo. Por eso creamos un flujo de trabajo basado en las capacidades CI/CD de Azure DevOps (ADO).

Nota: hemos utilizado ADO pero puede hacer lo mismo con GitHub, GitLab o Bitbucket.

He aquí el proceso final.

Este flujo de trabajo totalmente automatizado funciona muy bien. Las pruebas detectan los fallos en una fase temprana de la tubería de CI. Y la revisión obligatoria es también una forma de prevenir incidentes.

Además, los pull requests sirven como una especie de documentación de todas las demandas.

Hace poco menos de un año que empezamos a utilizar esta solución. Aunque requirió una inversión de tiempo inicial para la implantación, mereció totalmente la pena.

Ahora pasamos más tiempo discutiendo con los usuarios sobre sus peticiones y no en la implementación real. La mayoría de las peticiones pueden resolverse en unas 10 líneas de YAML. Esto es muy eficiente y se escala bien. Seguimos acogiendo a nuevos usuarios y podemos hacer frente a la demanda. Además, hemos resuelto los problemas iniciales. Así pues, ¡todo un éxito!