Control de acceso Snowflake a escala

Cada vez son más las empresas que sitúan a Snowflake en el centro de sus plataformas data . Aunque se trate de una solución gestionada, hay que administrar el entorno. Puede ser un reto, sobre todo para las grandes empresas.

Uno de los retos es el control de acceso. Es una pieza fundamental de cualquier programa de gobernanza de data . Snowflake ofrece funciones listas para usar que ayudan a afrontar este reto. Pero cuando se tienen docenas de usuarios y terabytes de data, las funciones incorporadas no bastan. Necesita pensar en una estrategia para gestionar su cuenta.

Hemos pasado por eso. Para uno 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 describe las principales conclusiones del año pasado.

Antes de unirnos a Compañia, la cuenta estaba configurada y se habían implementado un montón de buenas ideas. Se habían creado roles personalizados. 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:

Hemos optado por definir los roles de acceso a nivel de base de datos. Facilita la replicación de los privilegios de un entorno a otro mediante la clonación de copia cero. También fue un compromiso entre la flexibilidad que concedemos a los usuarios finales y la aplicación estricta del principio del mínimo privilegio.

A nivel de la base de datos, 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 ilustra nuestro marco. Las flechas representan subvenciones.

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

Configuramos Single Sign On para permitir a los usuarios de Snowflake iniciar sesión a través de Azure Active Directory (AAD). Así, eliminamos la complejidad de mantener dos bases de datos de usuarios y el proceso de baja fue más robusto. De hecho, sólo teníamos que dar de baja al usuario en AAD y la baja se replicaba automáticamente en Snowflake.

Como existe un mapeo entre los grupos AD y los roles en Snowflake, pudimos otorgar 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 introdujimos las cuentas de servicio. La gestión de las cuentas de servicio es muy similar a lo que acabamos de describir. La única diferencia es que creamos un rol funcional para cada cuenta de servicio. Existe una relación de uno a uno entre las cuentas de servicio y sus roles. 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, como era muy manual, también era propenso a errores. Estaba clara la necesidad de una herramienta que automatizara esas tareas.

Teníamos varias opciones:

Finalmente creamos un CLI en Python.

Preferimos usar Terraform para desplegar infraestructura y sólo infraestructura. Comportamientos no deseados pueden ocurrir cuando se empieza 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 ejecutas 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 la diferencia entre la configuración y el entorno remoto y aplica los cambios necesarios. Esto nos permite evitar cualquier tiempo de inactividad.

Al principio ejecutamos esta herramienta localmente. 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 de CI/CD de Azure DevOps (ADO).

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

Este es el proceso final.

Este flujo de trabajo totalmente automatizado funciona muy bien. Las pruebas detectan fallos en una fase temprana del proceso 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 inicial de tiempo 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 escalable. Seguimos dando la bienvenida a nuevos usuarios y podemos hacer frente a la demanda. Además, hemos resuelto los problemas iniciales. Así pues, ¡todo un éxito!