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 descubre los objetos disponibles en Snowflake y extrae la información técnica de los activos seleccionados (tablas, vistas y otros objetos tabulares). 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.

El plugin extrae los siguientes atributos, que deben llamarse igual en la tabla attribute_definition, campo name, para que aparezcan en la plantilla:

• catalog, con el valor de catalog en la base de datos.

• schema, con el valor de schema en la base de datos.

• physicalName y name con el mismo valor, el nombre de la tabla.

• path, con la concatenación de los valores de catalog, schema y table.

• infrastructure, technology y zone, con el valor seleccionado.

• tags, para tags creados de forma explícita en el activo.

• inheritedTags, para tags heredados de activos ancestros (Cuenta > Database > Schema).

También se envían los siguientes atributos relativos a los dataset_fields del recurso solicitado:

• name y physicalName, con el valor del campo.

• defaultValue, valor por defecto del campo.

• fieldDataType, tipo de dato del campo.

• length, tamaño del campo.

• incrementalField, indica si es un campo incremental.

• position, posición que ocupa el campo.

• precision, precisión del campo.

• nullable, indica si el campo admite nulos.

• pk, indica si el campo es clave primaria.

• description, descripción del campo.

• tags e inheritedTags, tags explícitos y heredados (Cuenta > Database > Schema > Tabla/Vista).

Los atributos a crear en Anjana deben tener los siguientes tipos:

El plugin es capaz de realizar la extracción de metadatos de tablas, vistas y vistas materializadas de Snowflake.

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.

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) y activado el SSO de Azure. 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)

• Eliminación de roles cuando procede (al eliminar o expirar un DSA).

• Tratamiento idempotente de operaciones repetidas.

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:

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.

Credenciales requeridas

Extracción de metadatos y muestreo

• Usuario o rol con permisos USAGE sobre la base de datos y el esquema donde están las tablas/vistas que se quieren gobernar.

• Usuario o rol con permisos REFERENCE sobre las tablas o vistas de las que se extrae el metadata.

• Usuario o rol con permisos SELECT sobre las tablas o vistas de las que se obtiene el muestreo de datos.

Gestión de permisos

La identidad técnica del plugin debe disponer de privilegios suficientes para crear roles y administrar concesiones (por ejemplo, CREATE ROLE sobre la cuenta y los GRANT ... WITH GRANT OPTION necesarios sobre database, schemas y tablas, así como USAGE sobre el warehouse).

Autenticación y autorización

OAuth2 con Entra ID (External OAuth)

Para conectarse de forma segura a Snowflake se utiliza OAuth2 con Microsoft Entra ID como proveedor de identidad, lo que permite obtener un token de acceso y autenticarse sin usuario ni contraseña. El flujo empleado es client_credentials, adecuado para procesos servidor a servidor: se registra una aplicación en Entra ID, se genera un secreto de cliente y se configuran los permisos; en Snowflake se crea la integración de seguridad correspondiente y se asocia la identidad técnica a un rol con los permisos necesarios.

CREATE SECURITY INTEGRATION anjana_oauth_azure_1
    TYPE = external_oauth
    ENABLED = true
    EXTERNAL_OAUTH_TYPE = azure
    EXTERNAL_OAUTH_ISSUER = 'https://sts.windows.net/{tenant}/'
    EXTERNAL_OAUTH_AUDIENCE_LIST = ('api://{app-id}')
    EXTERNAL_OAUTH_JWS_KEYS_URL = 'https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys'
    EXTERNAL_OAUTH_TOKEN_USER_MAPPING_CLAIM = 'sub'
    EXTERNAL_OAUTH_SNOWFLAKE_USER_MAPPING_ATTRIBUTE = 'login_name';

Una vez completada la configuración en Entra ID y Snowflake, se añaden los datos OAuth al fichero application.yaml del plugin:

oauth:
  token-url: xxxx       # endpoint de Entra ID al que se solicita el token
  client-id: xxxx       # aplicación registrada en Entra ID
  client-secret: xxxx   # secreto de la aplicación
  grant-type: client_credentials
  scope: xxxx           # ámbito solicitado para obtener un token válido para Snowflake

SCIM de Entra ID con Snowflake

SCIM sincroniza identidades desde Entra ID hacia Snowflake: los usuarios y grupos gestionados en Entra ID se aprovisionan automáticamente en Snowflake, donde los grupos se representan como roles. En Snowflake se crea una integración SCIM con su rol de aprovisionamiento; en Entra ID se configura la Enterprise Application de Snowflake, se activa el aprovisionamiento y se establece el endpoint SCIM junto con el token generado desde Snowflake.

El plugin no llama directamente al endpoint SCIM de Snowflake, sino que invoca el job de provisioning de la Enterprise Application en Entra ID mediante Microsoft Graph. La configuración SCIM se añade en application.yaml:

scim:
  enabled: true  # Enables o disables the use of SCIM in the plugin
  tenant-id: xxxx   # It corresponds to the Entra ID application that allows calling Microsoft Graph
  client-id: xxxx  # It corresponds to the Entra ID application that allows calling Microsoft Graph
  client-secret: xxxx   # It corresponds to the Entra ID application that allows calling Microsoft Graph
  scope: https://graph.microsoft.com/.default
  graph-base-url: https://graph.microsoft.com/v1.0
  snowflake-app-name: Snowflake
  service-principal-id: xxxx   # Enterprise Application de Snowflake
  job-id: xxxx                 # job de provisioning
  user-rule-id: xxxx
  group-rule-id: xxxx          # regla de sincronización de grupos
  role-sync-max-attempts: 60
  role-sync-backoff-ms: 5000

Con SCIM activo, createGroup no crea directamente el rol en Snowflake: el plugin espera a que exista el grupo en Entra ID, lanza el aprovisionamiento bajo demanda mediante Microsoft Graph y comprueba que el rol aparece en Snowflake. En addUser, si SCIM está disponible, sincroniza la pertenencia del usuario al grupo en Entra ID y valida que el rol queda concedido al usuario. Si SCIM no está activo, addUser realiza el GRANT ROLE directamente. Las operaciones de baja no dependen de SCIM: deleteGroup ejecuta DROP ROLE y removeUser ejecuta REVOKE ROLE, evitando depender del deprovisioning asíncrono de Entra ID.

El aprovisionamiento on-demand se realiza sobre el endpoint de provisioning del service principal:

POST /servicePrincipals/{servicePrincipalId}/synchronization/jobs/{jobId}/provisionOnDemand

Operaciones del plugin

El plugin implementa las siguientes operaciones:

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).