Snowflake (API nativa)
Esta página documenta la integración de Anjana Data Platform con Snowflake mediante el plugin tot-plugin-snowflake basado en la Snowflake SQL API (acceso REST) y autenticación External OAuth con Microsoft Entra ID. A diferencia de la integración vía conector JDBC (documentada en la página Snowflake), este plugin opera sobre las APIs nativas de Snowflake y amplía el alcance con gestión de permisos de acceso. Cubre tres bloques funcionales: extracción de metadatos, muestreo de datos y gestión de permisos.
Modelo de integración
El plugin tot-plugin-snowflake se integra con Snowflake a través de la Snowflake SQL API, un mecanismo de acceso basado en servicios REST que permite ejecutar sentencias SQL mediante peticiones HTTP, sin necesidad de una conexión persistente vía JDBC. El usuario inicia una operación desde Anjana Data, que se envía al plugin; este solicita previamente un access token al proveedor de identidad (Entra ID) mediante OAuth2, lo incorpora en la cabecera Authorization e invoca la Snowflake SQL API, que ejecuta la consulta y devuelve el resultado para su procesamiento en Anjana.
Extracción de metadatos
El plugin es capaz de realizar la extracción de metadatos de tablas, vistas y vistas materializadas de Snowflake así como de las batabase y schemas a los que pertenecen. El plugin descubre los objetos disponibles en Snowflake y extrae la información técnica de los activos seleccionados y los importa en entidades de subtipo DATASET y DATASET_FIELD. Este bloque incluye:
Descubrimiento de bases de datos y esquemas.
Listado de objetos tabulares disponibles.
Extracción de metadatos del objeto y de sus columnas.
Metadatos contextuales de database y schema.
Tags nativos de Snowflake, incluyendo los heredados de activos ancestros.
Para consultar el listado de metadatos que Anjana Data descubre para los distintos tipos de activos de Snowflake y cómo se mapean con los atributos de las plantillas DATASET y DATASET_FIELD, consulte la documentación de Snowflake (API Nativa) - Configuración Anjana
Muestreo de datos
El plugin permite obtener una muestra limitada de registros de un objeto Snowflake (tablas, vistas y vistas materializadas) para previsualizar y validar el contenido de los activos gobernados desde Anjana. El muestreo se realiza mediante consultas SELECT sobre el objeto, aplicando un límite de filas configurable mediante el parámetro sampleRows. Los valores de los campos sensibles (pi = true) se sustituyen por el string definido en obfuscation-string.
Para que la ofuscación de la muestra de datos surta efecto, debe incorporarse en la plantilla DATASET_FIELD el atributo pi y declararse de forma explícita.
Gestión de permisos
El plugin gestiona permisos de lectura sobre objetos Snowflake mediante un modelo basado en roles: los permisos se asignan a roles de Snowflake (que representan los grupos del DSA), no directamente a los usuarios. La gestión se realiza por medio de Data Sharing Agreements (DSA) y requiere:
Tener desplegado el plugin de Entra ID (que controla grupos y usuarios) o utilizar la funcionalidad del physicalName del DSA para reutilización de grupos existentes
Tener activada la sincronización de usuarios para gestionar adecuadamente las adherencias.
Este bloque incluye:
Creación o reutilización de roles asociados a DSAs.
Concesión de permisos USAGE sobre database y schema, y SELECT sobre tablas, vistas u objetos tabulares contenidos en un DSA aprobado.
Revocación de permisos SELECT sobre objetos concretos (al eliminar o expirar objetos contenidos en un DSA).
Reasignación de permisos SELECT sobre un objeto que vuelve a estar activo en el DSA.
Eliminación de roles cuando procede (al eliminar o expirar un DSA).
Tratamiento idempotente de operaciones repetidas.
Cuando un objeto incluido en un DSA vuelve a estar activo (pasa de DISABLED a APPROVED), el plugin reasigna a los roles afectados los privilegios que le corresponden sobre ese objeto, mediante la operación editObject. El plugin identifica los DSAs en los que está incluido el objeto, deduce los roles que deben recuperar el acceso y les vuelve a conceder SELECT sobre el objeto, añadiendo USAGE sobre la base de datos y el esquema si el rol no lo tuviera ya. La operación es idempotente: si el privilegio ya está concedido, finaliza correctamente sin duplicar la concesión.
Eliminación de roles reutilizados. Cuando un DSA se ha configurado con physicalName para reutilizar un grupo existente, la operación deleteGroup ejecuta igualmente DROP ROLE sobre ese rol al expirar o eliminarse el DSA, sin distinguir si el rol fue creado por el plugin o preexistía. Si la identidad técnica del plugin tiene OWNERSHIP sobre el rol, este se eliminará. Conviene tenerlo en cuenta al reutilizar roles gestionados fuera de la plataforma
Snowflake SQL API
Petición a la API
La Snowflake SQL API permite ejecutar sentencias SQL mediante peticiones HTTP: el cliente envía la sentencia en el cuerpo de la solicitud y Snowflake procesa la operación y devuelve la respuesta. El acceso se realiza mediante OAuth: la aplicación obtiene previamente un access token y lo incorpora en la cabecera Authorization de cada petición, evitando enviar credenciales de usuario. Se utiliza External OAuth, de modo que el token no lo emite Snowflake sino el proveedor de identidad externo (Entra ID), y Snowflake lo valida a través de la integración de seguridad configurada.
Modelo de permisos basado en roles
El control de acceso de Snowflake se basa en un modelo orientado a roles. Se crean roles asociados a un conjunto de privilegios sobre objetos (bases de datos, esquemas, tablas) y posteriormente se asignan a los usuarios, que heredan automáticamente dichos permisos. Cualquier cambio sobre los privilegios de un rol repercute en todos sus usuarios, lo que facilita una gestión coherente, escalable y trazable. Por ello, los grupos del sistema se modelan como roles de Snowflake.
Permisos de consumo sobre los activos
Los permisos de consumo son los privilegios mínimos para acceder y consultar un activo sin capacidades de administración. Para acceder a un objeto no basta con el permiso sobre el propio objeto: se necesita además acceso sobre la base de datos y el esquema que lo contienen. El alcance del plugin contempla:
Nivel | Privilegio |
Base de datos | USAGE |
Schema | USAGE |
Tabla | SELECT |
Vista | SELECT |
Vista materializada | SELECT |
External table* | SELECT |
Dynamic table* | SELECT |
Iceberg table* | SELECT |
Event table* | SELECT |
De este modo, para un activo tabular el patrón mínimo de concesión es: USAGE sobre la base de datos, USAGE sobre el esquema y SELECT sobre la tabla o vista, otorgando acceso de lectura sin permisos de modificación ni administración.
Nota (*)
El alcance de la gestión de permisos cubre, cualquier objeto tabular sobre el que Snowflake admita una concesión de SELECT. La extracción de metadatos y el muestreo de datos, en cambio, se limitan a tablas, vistas y vistas materializadas. Un objeto de otro tipo puede gobernarse en un DSA y recibir permisos, pero sus metadatos técnicos no se importan ni se muestrea su contenido desde Anjana.
Ciclo de vida de los permisos USAGE
La revocación de permisos no es simétrica respecto a la concesión. La operación removeObject revoca únicamente el grant directo sobre el objeto, es decir, el privilegio SELECT. Los privilegios USAGE sobre la base de datos y el esquema no se revocan durante la vida del rol, ni siquiera cuando se retira del DSA el último activo de un schema.
Estos privilegios solo desaparecen cuando el rol se elimina con DROP ROLE, lo que ocurre al expirar o borrarse el DSA (deleteGroup) del rol de la version vigente. En la práctica, esto significa que un rol que ya no tiene SELECT sobre ningún objeto conserva el USAGE sobre las bases de datos y esquemas a los que accedió en algún momento. El USAGE sobre un schema no permite por sí mismo leer datos: sin SELECT sobre un objeto, el rol solo puede ver los metadatos del objeto.
Roles de versiones anteriores. Al modificar el contenido de un DSA ya aprobado, Anjana genera una nueva versión del acuerdo y el plugin crea un rol nuevo asociado a ella, en lugar de modificar el existente. El rol de la versión anterior no se revoca ni se elimina, y conserva los privilegios USAGE y SELECT que tuviera. Estos roles tampoco se eliminan al borrar el DSA, por lo que permanecen de forma indefinida en Snowflake. No suponen acceso indebido, ya que no conservan usuarios asignados, pero sí implican una acumulación de roles residuales que conviene tener en cuenta en auditorías de permisos.
Credenciales requeridas
Extracción de metadatos y muestreo
La identidad técnica del plugin debe disponer de privilegios suficientes para listar los objetos y extraer los metadatos. Para mas información revisar Snowflake (API Nativa) - Configuración Infra.
Gestión de permisos
La identidad técnica del plugin debe disponer de privilegios suficientes para ejecutar las siguientes sentencias sobre Snowflake:
SHOW ROLES,SHOW USERS,SHOW GRANTS TO ROLE,SHOW GRANTS TO USERySHOW GRANTS OF ROLE, para comprobar el estado actual antes de actuar (idempotencia).CREATE ROLEyDROP ROLE.GRANT/REVOKE USAGEsobre database y schema.GRANT/REVOKE SELECTsobre el objeto.GRANT/REVOKE ROLE TO/FROM USER.
Para mas información revisar Snowflake (API Nativa) - Configuración Infra.
Acceso al warehouse del usuario final
El plugin no concede USAGE sobre ningún warehouse a los roles de consumo que crea. El rol recibe USAGE sobre la base de datos y el esquema y SELECT sobre los objetos del DSA, pero no el recurso de cómputo necesario para ejecutar las consultas.
Por tanto, el usuario final debe disponer de acceso a un warehouse por otra vía, ajena al alcance del plugin: mediante su rol por defecto, mediante PUBLIC o mediante otro rol que ya tenga concedido en Snowflake. Se trata de un prerrequisito de la integración: sin acceso a warehouse, un usuario con un DSA aprobado sigue sin poder consultar el activo.
Si se quiere utilizar un único warehouse para el consumo gobernado, lo habitual es conceder USAGE sobre ese warehouse a un rol que todos los consumidores ya tengan, por ejemplo PUBLIC o un rol concedido a todos los usuarios de la organización.
Operaciones del plugin
El plugin implementa las siguientes operaciones:
Operación | Descripción |
| Descubre y lista las bases de datos, esquemas y objetos tabulares disponibles. |
| Extrae los metadatos técnicos detallados de un objeto y sus columnas. |
| Devuelve una muestra de registros del objeto (límite |
| Crea o reutiliza el rol de Snowflake asociado al DSA (vía SCIM cuando está activo) y le concede los permisos de consumo sobre los activos del DSA. |
| Vuelve a conceder al rol los privilegios que le corresponden sobre un objeto, cuando este pasa de nuevo a estar activo en el DSA. Operación inversa de |
| Revoca el privilegio |
| Elimina el rol mediante |
| Concede el rol al usuario (sincronización SCIM o |
| Revoca el rol del usuario mediante |
Configuración
Conectividad
La conectividad se realiza contra la Snowflake SQL API sobre la cuenta de Snowflake, autenticada mediante el token OAuth2 obtenido de Entra ID. Los parámetros de conexión, OAuth y SCIM se definen en el fichero application.yaml del plugin (bloques oauth y scim). Para mas información revisar Snowflake (API Nativa) - Configuración Infra y YAML Ejemplo
La tripleta de infrastructure/technology /zone seleccionada al importar objetos en Anjana debe coincidir con la configurada en el application.yaml del plugin para que la conexión se resuelva correctamente.
Para todos los plugins existen directrices comunes en los apartados de Configuración técnica y Tot despliegue de plugins. Además, para cada plugin se dispone de un YAML de ejemplo que facilita su puesta en marcha, con la descripción de cada propiedad y sus valores por defecto.